EA012918B1 - Системы и способы на основе механизма управления цифровыми правами - Google Patents
Системы и способы на основе механизма управления цифровыми правами Download PDFInfo
- Publication number
- EA012918B1 EA012918B1 EA200801117A EA200801117A EA012918B1 EA 012918 B1 EA012918 B1 EA 012918B1 EA 200801117 A EA200801117 A EA 200801117A EA 200801117 A EA200801117 A EA 200801117A EA 012918 B1 EA012918 B1 EA 012918B1
- Authority
- EA
- Eurasian Patent Office
- Prior art keywords
- content
- node
- όκμ
- access
- objects
- Prior art date
Links
- 238000000034 method Methods 0.000 title claims abstract description 365
- 230000007246 mechanism Effects 0.000 claims description 274
- 238000004891 communication Methods 0.000 claims description 175
- 230000009471 action Effects 0.000 claims description 112
- 238000007726 management method Methods 0.000 claims description 93
- 230000006870 function Effects 0.000 claims description 57
- 239000012634 fragment Substances 0.000 claims description 27
- 238000005516 engineering process Methods 0.000 claims description 18
- 238000012550 audit Methods 0.000 claims description 3
- 230000002829 reductive effect Effects 0.000 claims description 2
- 235000015250 liver sausages Nutrition 0.000 description 109
- 239000003795 chemical substances by application Substances 0.000 description 94
- 238000012546 transfer Methods 0.000 description 64
- 238000004806 packaging method and process Methods 0.000 description 37
- 230000000875 corresponding effect Effects 0.000 description 36
- 230000008569 process Effects 0.000 description 33
- 238000004422 calculation algorithm Methods 0.000 description 29
- 230000004044 response Effects 0.000 description 26
- 238000013475 authorization Methods 0.000 description 22
- 230000003993 interaction Effects 0.000 description 22
- 238000012795 verification Methods 0.000 description 22
- 230000002441 reversible effect Effects 0.000 description 19
- 238000012545 processing Methods 0.000 description 18
- 238000009826 distribution Methods 0.000 description 17
- 239000002131 composite material Substances 0.000 description 16
- 230000007704 transition Effects 0.000 description 15
- 230000014509 gene expression Effects 0.000 description 14
- 238000012360 testing method Methods 0.000 description 14
- 230000001012 protector Effects 0.000 description 12
- 235000014510 cooky Nutrition 0.000 description 11
- 230000008685 targeting Effects 0.000 description 11
- 238000009795 derivation Methods 0.000 description 10
- 230000036541 health Effects 0.000 description 10
- 239000000463 material Substances 0.000 description 10
- 238000003860 storage Methods 0.000 description 9
- 238000004458 analytical method Methods 0.000 description 8
- 238000013459 approach Methods 0.000 description 8
- 230000005540 biological transmission Effects 0.000 description 8
- 230000006378 damage Effects 0.000 description 8
- 238000013461 design Methods 0.000 description 8
- 230000027455 binding Effects 0.000 description 7
- 238000004364 calculation method Methods 0.000 description 7
- 230000008859 change Effects 0.000 description 7
- 230000000694 effects Effects 0.000 description 7
- 230000008901 benefit Effects 0.000 description 6
- 230000001010 compromised effect Effects 0.000 description 6
- 238000013500 data storage Methods 0.000 description 6
- 238000011156 evaluation Methods 0.000 description 6
- 238000012986 modification Methods 0.000 description 6
- 230000004048 modification Effects 0.000 description 6
- HEFNNWSXXWATRW-UHFFFAOYSA-N Ibuprofen Chemical compound CC(C)CC1=CC=C(C(C)C(O)=O)C=C1 HEFNNWSXXWATRW-UHFFFAOYSA-N 0.000 description 5
- 230000000903 blocking effect Effects 0.000 description 5
- 238000010586 diagram Methods 0.000 description 5
- 230000007717 exclusion Effects 0.000 description 5
- 238000009434 installation Methods 0.000 description 5
- CDBYLPFSWZWCQE-UHFFFAOYSA-L Sodium Carbonate Chemical compound [Na+].[Na+].[O-]C([O-])=O CDBYLPFSWZWCQE-UHFFFAOYSA-L 0.000 description 4
- 238000012937 correction Methods 0.000 description 4
- 230000008676 import Effects 0.000 description 4
- 238000005259 measurement Methods 0.000 description 4
- 239000000047 product Substances 0.000 description 4
- 230000001681 protective effect Effects 0.000 description 4
- 238000000926 separation method Methods 0.000 description 4
- 239000000243 solution Substances 0.000 description 4
- 101150003901 PRKD1 gene Proteins 0.000 description 3
- 239000008186 active pharmaceutical agent Substances 0.000 description 3
- 238000003491 array Methods 0.000 description 3
- 239000002956 ash Substances 0.000 description 3
- 238000010367 cloning Methods 0.000 description 3
- 150000001875 compounds Chemical class 0.000 description 3
- 230000007423 decrease Effects 0.000 description 3
- 235000011389 fruit/vegetable juice Nutrition 0.000 description 3
- 238000004519 manufacturing process Methods 0.000 description 3
- 230000001360 synchronised effect Effects 0.000 description 3
- 230000001960 triggered effect Effects 0.000 description 3
- 241000269350 Anura Species 0.000 description 2
- 101100456566 Caenorhabditis elegans dpy-22 gene Proteins 0.000 description 2
- 101100067649 Caenorhabditis elegans gta-1 gene Proteins 0.000 description 2
- 241000196324 Embryophyta Species 0.000 description 2
- 206010028980 Neoplasm Diseases 0.000 description 2
- 241000232219 Platanista Species 0.000 description 2
- 241000036848 Porzana carolina Species 0.000 description 2
- 101150004026 SOP1 gene Proteins 0.000 description 2
- 241001621721 Ziba Species 0.000 description 2
- 238000013474 audit trail Methods 0.000 description 2
- 201000011510 cancer Diseases 0.000 description 2
- 238000012790 confirmation Methods 0.000 description 2
- 230000001186 cumulative effect Effects 0.000 description 2
- 230000003247 decreasing effect Effects 0.000 description 2
- 238000001514 detection method Methods 0.000 description 2
- 238000011161 development Methods 0.000 description 2
- 230000018109 developmental process Effects 0.000 description 2
- 210000001061 forehead Anatomy 0.000 description 2
- 210000003128 head Anatomy 0.000 description 2
- 238000007689 inspection Methods 0.000 description 2
- 238000011835 investigation Methods 0.000 description 2
- 230000000670 limiting effect Effects 0.000 description 2
- 230000001343 mnemonic effect Effects 0.000 description 2
- 238000005067 remediation Methods 0.000 description 2
- 230000005236 sound signal Effects 0.000 description 2
- 230000008838 symmetric binding Effects 0.000 description 2
- 108091068160 08 family Proteins 0.000 description 1
- 101100165535 Arabidopsis thaliana BLH4 gene Proteins 0.000 description 1
- 235000014698 Brassica juncea var multisecta Nutrition 0.000 description 1
- 102100025248 C-X-C motif chemokine 10 Human genes 0.000 description 1
- 101100348341 Caenorhabditis elegans gas-1 gene Proteins 0.000 description 1
- 101150094716 Ciao1 gene Proteins 0.000 description 1
- 101100055841 Danio rerio apoa1 gene Proteins 0.000 description 1
- 101100505063 Escherichia coli (strain K12) garK gene Proteins 0.000 description 1
- 101100126274 Escherichia coli (strain K12) iraM gene Proteins 0.000 description 1
- 244000187656 Eucalyptus cornuta Species 0.000 description 1
- 241001065200 Fridericia rego Species 0.000 description 1
- 241000197200 Gallinago media Species 0.000 description 1
- 241000948258 Gila Species 0.000 description 1
- 244000068988 Glycine max Species 0.000 description 1
- 235000010469 Glycine max Nutrition 0.000 description 1
- WTDRDQBEARUVNC-LURJTMIESA-N L-DOPA Chemical compound OC(=O)[C@@H](N)CC1=CC=C(O)C(O)=C1 WTDRDQBEARUVNC-LURJTMIESA-N 0.000 description 1
- 101100447658 Mus musculus Gas1 gene Proteins 0.000 description 1
- 244000063675 Orchis mascula Species 0.000 description 1
- 238000012356 Product development Methods 0.000 description 1
- 235000014443 Pyrus communis Nutrition 0.000 description 1
- 241000251184 Rajiformes Species 0.000 description 1
- 101100222379 Rattus norvegicus Cxcl10 gene Proteins 0.000 description 1
- 241000124033 Salix Species 0.000 description 1
- VYPSYNLAJGMNEJ-UHFFFAOYSA-N Silicium dioxide Chemical compound O=[Si]=O VYPSYNLAJGMNEJ-UHFFFAOYSA-N 0.000 description 1
- 101000621954 Synechococcus sp. (strain JA-2-3B'a(2-13)) Vitamin K epoxide reductase homolog Proteins 0.000 description 1
- 102100023485 Vitamin K epoxide reductase complex subunit 1 Human genes 0.000 description 1
- 206010000210 abortion Diseases 0.000 description 1
- 230000006399 behavior Effects 0.000 description 1
- 230000033228 biological regulation Effects 0.000 description 1
- 230000001413 cellular effect Effects 0.000 description 1
- 238000012512 characterization method Methods 0.000 description 1
- 239000007795 chemical reaction product Substances 0.000 description 1
- 238000004140 cleaning Methods 0.000 description 1
- 230000001276 controlling effect Effects 0.000 description 1
- 238000013144 data compression Methods 0.000 description 1
- 238000013502 data validation Methods 0.000 description 1
- 101150047356 dec-1 gene Proteins 0.000 description 1
- 230000007123 defense Effects 0.000 description 1
- 230000001934 delay Effects 0.000 description 1
- 230000007613 environmental effect Effects 0.000 description 1
- VJYFKVYYMZPMAB-UHFFFAOYSA-N ethoprophos Chemical compound CCCSP(=O)(OCC)SCCC VJYFKVYYMZPMAB-UHFFFAOYSA-N 0.000 description 1
- 238000007667 floating Methods 0.000 description 1
- 230000036039 immunity Effects 0.000 description 1
- 230000006872 improvement Effects 0.000 description 1
- 230000000977 initiatory effect Effects 0.000 description 1
- 238000002347 injection Methods 0.000 description 1
- 239000007924 injection Substances 0.000 description 1
- 230000033001 locomotion Effects 0.000 description 1
- JEJGUIDNYBAPGN-UHFFFAOYSA-N methylenedioxydimethylamphetamine Chemical compound CN(C)C(C)CC1=CC=C2OCOC2=C1 JEJGUIDNYBAPGN-UHFFFAOYSA-N 0.000 description 1
- 238000013508 migration Methods 0.000 description 1
- 230000005012 migration Effects 0.000 description 1
- 239000000203 mixture Substances 0.000 description 1
- 238000012544 monitoring process Methods 0.000 description 1
- XBGNERSKEKDZDS-UHFFFAOYSA-N n-[2-(dimethylamino)ethyl]acridine-4-carboxamide Chemical compound C1=CC=C2N=C3C(C(=O)NCCN(C)C)=CC=CC3=CC2=C1 XBGNERSKEKDZDS-UHFFFAOYSA-N 0.000 description 1
- 231100000957 no side effect Toxicity 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 230000008520 organization Effects 0.000 description 1
- 238000012858 packaging process Methods 0.000 description 1
- 238000012856 packing Methods 0.000 description 1
- 230000002093 peripheral effect Effects 0.000 description 1
- 230000002085 persistent effect Effects 0.000 description 1
- BZQFBWGGLXLEPQ-REOHCLBHSA-N phosphoserine Chemical compound OC(=O)[C@@H](N)COP(O)(O)=O BZQFBWGGLXLEPQ-REOHCLBHSA-N 0.000 description 1
- 230000002028 premature Effects 0.000 description 1
- 230000002265 prevention Effects 0.000 description 1
- 238000007639 printing Methods 0.000 description 1
- 238000004886 process control Methods 0.000 description 1
- 238000011867 re-evaluation Methods 0.000 description 1
- 230000001105 regulatory effect Effects 0.000 description 1
- 239000013049 sediment Substances 0.000 description 1
- 230000011218 segmentation Effects 0.000 description 1
- 230000011664 signaling Effects 0.000 description 1
- 230000007474 system interaction Effects 0.000 description 1
- 230000009466 transformation Effects 0.000 description 1
- 238000012384 transportation and delivery Methods 0.000 description 1
- 238000010200 validation analysis Methods 0.000 description 1
- 101150041325 vopp1 gene Proteins 0.000 description 1
- 239000003643 water by type Substances 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/60—Protecting data
-
- 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
-
- 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/101—Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM] by binding digital rights to specific entities
- G06F21/1013—Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM] by binding digital rights to specific entities to locations
-
- 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/20—Point-of-sale [POS] network systems
- G06Q20/202—Interconnection or interaction of plural electronic cash registers [ECR] or to host computer, e.g. network details, transfer of information from host to ECR or from ECR to ECR
-
- 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/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
- H04L63/0492—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 by using a location-limited connection, e.g. near-field communication or limited proximity 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
-
- 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
-
- 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/30—Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy
- H04L9/3006—Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy underlying computational problems or public-key parameters
- H04L9/302—Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy underlying computational problems or public-key parameters involving the integer factorization problem, e.g. RSA or quadratic sieve [QS] schemes
-
- 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/3236—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 cryptographic hash functions
- H04L9/3242—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 cryptographic hash functions involving keyed hash functions, e.g. message authentication codes [MACs], CBC-MAC or HMAC
-
- 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/3247—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 digital signatures
-
- 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
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F2221/2111—Location-sensitive, e.g. geographical location, GPS
-
- 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
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/12—Applying verification of the received information
- H04L63/123—Applying verification of the received information received data contents, e.g. message integrity
Abstract
Описаны системы и способы осуществления управления цифровыми правами. В одном варианте осуществления предусмотрен механизм управления цифровыми правами, который оценивает лицензию, связанную с защищенным контентом, для определения, авторизован ли запрашиваемый доступ или иное использование контента. В некоторых вариантах осуществления лицензии содержат программы управления, которые выполняются механизмом управления цифровыми правами.
Description
Эта заявка притязает на приоритет предварительной патентной заявки США № 60/728,089, поданной 18 октября 2005 г., предварительной патентной заявки США № 60/772,024, поданной 9 февраля 2006 г., предварительной патентной заявки США № 60/744,574, поданной 10 апреля 2006 г., предварительной патентной заявки США № 60/791,179, поданной 10 апреля 2006 г., предварительной патентной заявки США № 60/746,712, поданной 8 мая 2006 г., предварительной патентной заявки США № 60/798,925, поданной 8 мая 2006 г., и предварительной патентной заявки США № 60/835,061, поданной 1 августа 2006 г. Предварительные патентные заявки США №№ 60/728,089, 60/772,024, 60/744,574, 60/791,179, 60/746,712, 60/798,925 и 60/835,061 включены сюда посредством ссылки в полном объеме для любых целей.
Определение авторских прав
Часть раскрытия этого патентного документа содержит материал, подлежащий защите авторских прав. Владелец авторских прав не возражает против факсимильного воспроизведения кем-либо патентного документа или раскрытия патента, представленного в виде файла или записи в Патентное Ведомство, но в остальном сохраняет за собой все авторские права.
Уровень техники
В современных вычислительных системах часто бывает желательно ограничивать доступ к ресурсам электронного контента, услуг и/или обработки, и/или разрешать осуществлять определенные действия только определенным сущностям. Для обеспечения такого управления были разработаны или предложены различные методы. Эти методы часто называют методами управления цифровыми правами (ΌΒΜ), поскольку, в целом, их целью является регулирование прав различных сущностей в отношении цифрового или иного электронного контента, услуг или ресурсов. Проблема, с которой сталкиваются многие методы, отвечающие уровню техники, заключается в том, что они чрезмерно сложны, обременены большим количеством ограничений, сравнительно «негибки», неспособны обеспечивать определенные естественные типы соотношений и процессов, и/или неспособны взаимодействовать с другими системами ΌΒΜ.
Здесь описаны системы и способы, относящиеся к усовершенствованным методам ΌΒΜ, которые можно использовать для решения некоторых или всех этих проблем. Очевидно, что варианты осуществления описанного здесь изобретения можно реализовать по-разному, в том числе посредством процессов, аппаратов, систем, устройства, способов, компьютерно-считываемых носителей и/или их комбинации.
Существующие системы для управления доступом к контенту иногда включают в себя компоненты, которые обращаются к лицензии в связи с авторизацией доступа к электронному контенту. Однако такие компоненты обычно осуществляют негибкие вычисления цепей или графов информации управления правами, связей или узлов, связанных с лицензией. Они часто неспособны адаптироваться к различным схемам авторизации и/или работать с определенными системами ΌΒΜ для авторизации доступа к контенту. Варианты осуществления настоящего изобретения преодолевают такие недостатки за счет сохранения, использования и/или выполнения дополнительных процедур или программ управления в связи с лицензией, что позволяет обеспечивать динамические особенности авторизации, обеспечивать авторизацию распределенных ресурсов и/или другие функции доступа к потоку.
Кроме того, многие существующие системы предназначены только для случаев, когда поддерживаются простые данные, связанные с авторизацией/состоянием. Эти системы неспособны разрешать ситуации, когда для авторизации доступа может потребоваться зависимость от множественных уровней данных, например определение условий на основании ранее выведенных данных, связанных с другими узлами. Варианты осуществления настоящего изобретения преодолевают эти недостатки за счет реализации базы данных состояний совместно с программами управления ΌΒΜ для обеспечения особенностей хранения состояний, которые являются защищенными, обеспечивают устойчивые информационные состояния от вызова к вызову, или иначе обеспечивают функции чтения и записи состояний, что позволяет улучшать выполнение программ управления и/или осуществлять более эффективную авторизацию доступа.
Дополнительно, существующие системы могут реализовать лицензии или структуры ΌΒΜ, включающие в себя компоненты, которые предусматривают использование открытых ключей для защиты компонентов лицензии. Однако недостатки этих систем включают в себя возможность того, что хакеры могут подделать цифровые подписи, необходимые для доступа или реализации лицензии, или иначе воспользоваться соответствующими соотношениями, существующими в структуре лицензии ΌΒΜ. Один или несколько вариантов осуществления настоящего изобретения преодолевают такие недостатки путем реализации цифровой и/или блокирующей подписи объектов «лицензия», включающей в себя использование конкретных защищенных ключей. Преимущества этих вариантов осуществления включают в себя предотвращение неавторизованного доступа посредством открытых ключей, а также соответствующих особенностей, выведенных из соотношений между элементами лицензии.
Другие существующие системы могут включать в себя компоненты, которые могут определять близость между первой сущностью и второй сущностью, например, между двумя сущностями управления правами. Такие системы могут применять правила, указывающий, что фрагмент защищенного контента нельзя копировать за пределы определенной среды, например, путем реализации громоздких процедур
- 1 012918 проверки близости. Однако недостатком этих систем является то, что они не способны также предоставлять защиту защищенному контенту без ненужного принудительного осуществления проверки близости. Варианты осуществления настоящего изобретения преодолевают этот и другие недостатки за счет обеспечения лаконичного протокола обнаружения близости, защищенного особенностями, связанными с передачей случайных чисел и/или секретных порождающих чисел. Соответствующие преимущества одного или нескольких вариантов осуществления включают в себя криптографическую нереализуемость для нарушителя определение правильного ответа, даже в случае перехвата запроса.
В итоге, существует необходимость в системах, которые могут адекватно авторизовать доступ к электронному контенту, не прибегая к чрезмерно сложным, обремененным большим количеством ограничений и/или сравнительно негибким методам, в системах, которые способны обеспечивать определенные естественные типы соотношений и процессов, и/или в системах, которые способны взаимодействовать с другими системами ΌΒΜ.
Раскрытие изобретения
Системы, способы и изделия производства, отвечающие изобретению, относятся к авторизации доступа к электронному контенту и связанной с этим обработке данных.
В одном иллюстративном варианте осуществления, предусмотрен способ авторизации доступа к фрагменту электронного контента, хранящемуся в памяти. Способ, согласно этому иллюстративному варианту осуществления, может включать в себя прием запрос на доступ к электронному контенту, извлечение лицензии, связанной с электронным контентом, и выполнение первой программы управления с использованием механизма управления цифровыми правами для определения, можно ли удовлетворить запрос. Другие иллюстративные варианты осуществления могут включать в себя вычисление одного или нескольких объектов «связь», хранящихся в памяти, и выполнение второй программы управления для определения, действительна(ы) ли связь(и) и/или выполняются ли одно или несколько условий.
Следует понимать, что вышеизложенное общее описание и нижеследующее подробное описание носят исключительно иллюстративный и пояснительный характер и не призваны ограничивать изобретение. Кроме того, могут быть обеспечены признаки и/или вариации помимо изложенных здесь. Например, настоящее изобретение может относиться к различным комбинациям и подкомбинациям раскрытых признаков и/или комбинациям и подкомбинациям некоторых других признаков, раскрытых ниже в подробном описании.
Краткое описание чертежей
Изобретение легче понять, обратившись к нижеследующему подробному описанию, приведенному совместно с прилагаемыми чертежами, в которых:
фиг. 1 - иллюстративная система управления использованием электронного контента;
фиг. 2 - более подробный пример системы, которую можно использовать для практического применения вариантов осуществления изобретения;
фиг. 3 - демонстрирует действие иллюстративного механизма управления цифровыми правами (ΌΚΜ) в сети, которая использует ΌΒΜ;
фиг. 4 - совокупность узлов и связей, используемая для моделирования соотношений в системе ΌΡΜ;
фиг. 5 - логическая блок-схема, демонстрирующая, как вариант осуществления механизма ΌΚΜ может определять, авторизовано ли запрошенное действие;
фиг. 6 - пример лицензии ΌΚΜ согласно одному варианту осуществления изобретения;
фиг. 7А и 7В - пример использования агентов в одном варианте осуществления;
фиг. 8 - пример лицензии ΌΒΜ;
фиг. 9 - более подробный пример того, как механизм ΌΚΜ может определять, авторизовано ли запрошенное действие;
фиг. 10 - более подробный пример того, как механизм ΌΚΜ выполняет программу управления в одном варианте осуществления;
фиг. 11 - иллюстративный вариант осуществления механизма ΌΚΜ, выполняющегося на устройстве;
фиг. 12 - логическая блок-схема, демонстрирующая этапы, предусмотренные при выполнении программы управления в одном варианте осуществления;
фиг. 13 - элементы, составляющие клиентское приложение, потребляющее контент, в одном варианте осуществления;
фиг. 14 - элементы, составляющие приложение упаковки контента в одном варианте осуществления;
фиг. 15 - механизм вывода ключа согласно одному варианту осуществления;
фиг. 16 - пример системы ΌΒΜ;
фиг. 17 - пример системы ΌΚΜ, которая обеспечивает временный вход;
фиг. 18 - высокоуровневая архитектура иллюстративной системы для управления документацией предприятия;
фиг. 19 - пример того, как систему, например, показанную на фиг. 18, можно использовать для
- 2 012918 управления доступом к документу или другим его использованием;
фиг. 20 - дополнительный пример того, как систему, например, показанную на фиг. 18, можно использовать для управления доступом к документу или другим его использованием;
фиг. 21 - дополнительные особенности примера, показанного на фиг. 20;
фиг. 22 - другая иллюстративная система для управления электронным контентом на предприятии;
фиг. 23 - применение описанных здесь систем и способов для управления записями системы здравоохранения;
фиг. 24 - демонстрирует, как представленные здесь системы и способы можно использовать в контексте службы электронной подписки;
фиг. 25 - демонстрирует, как описанные здесь системы и способы можно использовать в контексте домена домашней сети;
фиг. 26 - взаимодействия, которые имеют место между приложением хоста и механизмом клиента ΌΚΜ в одном иллюстративном варианте осуществления;
фиг. 27 - взаимодействия, которые имеют место между приложением хоста и механизмом упаковки в одном иллюстративном варианте осуществления;
фиг. 28А - более подробная иллюстрация лицензии согласно одному варианту осуществления;
фиг. 28В - соотношение между связями и узлами в одном иллюстративном варианте осуществления;
фиг. 29 - операционная среда иллюстративной реализации виртуальной машины;
фиг. 30 - структура данных расширенного блока состояний согласно одному варианту осуществления;
фиг. 31А - образ памяти для сегмента данных в одном варианте осуществления;
фиг. 31В - пример образа памяти для сегмента кода в одном варианте осуществления;
фиг. 31С - пример образа памяти для элемента экспорта в одном варианте осуществления;
фиг. 31Ό - общий пример элемента таблицы экспорта в одном варианте осуществления;
фиг. 31Е - пример элемента таблицы экспорта для иллюстративной точки входа;
фиг. 32 - пример протокола передачи лицензии;
фиг. 33 - другой пример протокола передачи лицензии согласно одному варианту осуществления; фиг. 34 - механизм защиты целостности объектов «лицензия» в одном варианте осуществления; фиг. 35 - механизм защиты целостности объектов «лицензия» в другом варианте осуществления; фиг. 36 - протокол проверки близости согласно одному варианту осуществления;
фиг. 37 - демонстрирует использование протокола проверки близости согласно одному варианту осуществления;
фиг. 38 - взаимодействие между клиентом и сервером лицензий в одном варианте осуществления;
фиг. 39 - более подробная иллюстрация взаимодействия между клиентом и сервером лицензий в одном варианте осуществления;
фиг. 40 - пример сущности с множественными ролями;
фиг. 41 - протокол загрузки согласно одному варианту осуществления;
фиг. 42 - соотношение между с14п-ех и иллюстративной ХМЬ-каноникализацией в одном варианте осуществления.
Осуществление изобретения
Ниже представлено подробное описание изобретения. Хотя описано несколько вариантов осуществления, следует понимать, что изобретение не ограничивается каким-либо вариантом осуществления, но, напротив, охватывает многочисленные альтернативы, модификации и эквиваленты. Кроме того, хотя в нижеследующем описании приведены многочисленные конкретные детали для обеспечения исчерпывающего понимания изобретения, некоторые варианты осуществления можно применять на практике без некоторых или всех этих деталей. Кроме того, для ясности, определенные технические сведения, известные в уровне техники, не описаны подробно во избежание ненужного затемнения изобретения.
В совместно поданной патентной заявке США № 10/863,551, № 2005/0027871 А1 (далее - заявке '551), которая, таким образом, включена сюда посредством ссылки, описаны варианты осуществления архитектуры управление цифровыми правами (ΌΚΜ) и нового механизма ΌΚΜ, которые преодолевают некоторые недостатки, характерные для многих предыдущих реализаций ΌΚΜ. В данной заявке описаны усовершенствования, расширения и модификации, а также альтернативные варианты осуществления архитектуры и механизма ΌΚΜ, описанных в заявке '551, а также новые компоненты, архитектуры и варианты осуществления. Таким образом, очевидно, что описанный здесь материал можно использовать в контексте архитектуры и/или механизма ΌΚΜ, например, описанных в заявке '551, а также в других контекстах.
1. Иллюстративная система ΌΚΜ.
На фиг. 1 показана иллюстративная система 100 для управления электронным контентом. Согласно фиг. 1, сущность 102, обладающая правами на электронный контент 103, упаковывает контент для распространения и потребления конечными пользователями 108а-е (совместно именуемыми конечными пользователями 108, где позиция 108 в равной степени относится к конечному пользователю и к вычис
- 3 012918 лительной системе конечного пользователя, а к чему именно, будет ясно из контекста). Например, сущность 102 может являться владельцем, создателем или поставщиком контента, например, музыкантом, киностудией, издательством, компанией по разработке программного обеспечения, автором, поставщиком услуг мобильной связи, службой загрузки или подписки на контент в интернете, поставщиком кабельного или спутникового телевещания, служащим корпорации и т.п., или сущностью, действующей от его имени, и контент 103 может содержать любой электронный контент, например цифровой видео-, аудио- или текстовый контент, фильм, песню, видеоигру, фрагмент программного обеспечения, сообщение электронной почты, текстовое сообщение, документ текстового редактора, отчет или любой другой развлекательный, деловой или другой контент.
В примере, показанном на фиг. 1, сущность 102 использует механизм упаковки 109, связывающий лицензию 106 с упакованным контентом 104. Лицензия 106 основана на политиках 105 или других желаниях сущности 102, и указывает разрешенные и/или запрещенные режимы использования контента и/или одно или несколько условий, которым должны удовлетворять режимы использования контента, или которые должны выполняться как условие или следствие использования. Контент также может быть защищен одним или несколькими криптографическими механизмами, например, методами шифрования или цифровой подписи, для чего доверенный орган 110 можно использовать для получения соответствующих криптографических ключей, сертификатов и/или т. п.
Согласно фиг. 1, упакованный контент 104 и лицензии 106 можно предоставлять конечным пользователям 108 любыми пригодными средствами, например, по сети 112 наподобие интернета, локальной сети 103, беспроводной сети, виртуальной частной сети 107, глобальной сети, и/или т.п., посредством кабельной, спутниковой, широковещательной или сотовой связи 114, и/или через записываемые носители 116, например, компакт-диск (0Ό). цифровой универсальный диск (НУО), карту флэш-памяти (например, карту 8ееигйу Ωί^ίΐαΐ (8Ό)), и/или т.п. Упакованный контент 104 можно доставлять пользователю совместно с лицензией 106 в одном пакете или передаче 113, или в отдельных пакетах или передачах, принимаемых от одного или разных источников.
Система конечного пользователя (например, персональный компьютер 108е, мобильный телефон 108а, телевизор и/или телевизионная приставка 108с, портативный аудио- и/или видеопроигрыватель, устройство чтения электронных книг и/или т. п.) содержит прикладное программное обеспечение 116, оборудование и/или специализированное логическое устройство, которое способно извлекать и представлять контент. Система пользователя также включает в себя программное обеспечение и/или оборудование, именуемое здесь механизмом 118 управления цифровыми правами, для оценивания лицензии 106, связанной с упакованным контентом 104, и применения ее условий (и/или разрешения приложению 116 применять эти условия), например, путем избирательного предоставления пользователю доступа к контенту только, если это разрешает лицензия 106. Механизм 118 управления цифровыми правами может быть структурно или функционально объединен с приложением 116 или может содержать отдельный фрагмент программного обеспечения и/или оборудования. Альтернативно или дополнительно, система пользователя, например система 108с, может осуществлять связь с удаленной системой, например системой 108Ь, (например, сервером, другим устройством в сети устройств пользователя, например, персональным компьютером или телевизионной приставкой, и/или т. п.), которое использует механизм управления цифровыми правами для определения 120, предоставлять ли пользователю доступ к контенту, ранее полученному или запрошенному пользователем.
Механизм управления цифровыми правами, и/или другое программное обеспечение, находящееся в системе пользователя или осуществляющее дистанционную связь с ней, также может записывать информацию, относящуюся к доступу пользователя к защищенному контенту или другому его использованию. В некоторых вариантах осуществления, эта информация, полностью или частично, может передаваться удаленной стороне (например, в расчетный центр 122, создателю, владельцу или поставщику контента 102, менеджеру пользователя, сущности, действующей от его имени, и/или т.п.), например, для использования при начислении выручки (например, гонорара, платы за развлечение и т.д.), определении предпочтений пользователя, применении системных политик (например, мониторинге использования конфиденциальной информации), и/или т.п. Очевидно, что, хотя фиг. 1 показана иллюстративная архитектура ΌΚΜ и совокупность иллюстративных соотношений, описанные здесь системы и способы можно применять на практике в любом подходящем контексте, и, таким образом, очевидно, что фиг. 1 приведена в целях иллюстрации и объяснения, но не в целях ограничения.
На фиг. 2 показан более подробный пример системы 200, которую можно использовать для практического применения вариантов осуществления изобретения. Например, система 200 может содержать вариант осуществления устройства 108 конечного пользователя, устройства 109 поставщика контента и/или т. п. Например, система 200 может содержать вычислительное устройство общего назначения, например, персональный компьютер 108е или сетевой сервер 105, или специализированное вычислительное устройство, например, сотовый телефон 108а, карманный персональный компьютер, портативный аудио- или видеопроигрыватель, телевизионную приставку, киоск, игровую систему и т.п. Система 200 обычно включает в себя процессор 202, память 204, пользовательский интерфейс 206, порт 207, куда вставляется сменная память 208, сетевой интерфейс 210 и одну или несколько шин 212 для соединения
- 4 012918 вышеупомянутых элементов. Работой системы 200 обычно управляет процессор 202, действующий под управлением программ, хранящихся в памяти 204. Память 204 обычно включает в себя высокоскоростную оперативную память (ОЗУ) и энергонезависимую память, например, магнитный диск и/или флэшЭСППЗУ. Некоторые участки памяти 204 могут быть заблокированы, что не позволяет другим компонентам системы 200 производить на них операции чтения и записи. Порт 207 может содержать дисковод или разъем памяти для приема компьютерно-считываемых носителей 208, например, дискет, ΟΌ-ΚΟΜ, ΌνΌ, карт памяти, δΌ-карт, других магнитных или оптических носителей и/или т.п. Сетевой интерфейс 210 обычно способен обеспечивать соединение между системой 200 и другими вычислительными устройствами (и/или сетями вычислительных устройств) через сеть 220, например, интернет или интрасеть (например, ЬЛЫ, νΑΝ, νΡΝ и т.д.), и может применять одну или несколько технологий связи для физического создания такого соединения (например, беспроводного, ЕФсгпсЕ и/или т.п.). В некоторых вариантах осуществления, система 200 также может включать в себя блок обработки 203, защищенный от злонамеренного использования пользователем системы 200 или другими сущностями. Такой защищенный блок обработки может способствовать повышению безопасности важных операций, например, управления ключами, проверки подписи, и других аспектов процесса управления цифровыми правами.
Согласно фиг. 2, память 204 вычислительного устройства 200 может включать в себя различные программы или модули, управляющие работой вычислительного устройства 200. Например, память 204 обычно включает в себя операционную систему 220 для управления выполнением приложений, работой периферийных устройств, и т.п.; приложение хоста 230 для представления защищенного электронного контента; и механизм ΏΚΜ 232 для реализации некоторых или всех описанных здесь функций управления правами. Как описано здесь в другом месте, механизм ΏΚΜ 232 может содержать, взаимодействовать с, и/или управлять различными другими модулями, например, виртуальной машиной 222 для выполнения программ управления и базой данных состояний 224 для хранения информации состояния, используемой виртуальной машиной 222, и/или одним или несколькими криптографическими модулями 226 для осуществления криптографических операций, например, шифрования и/или дешифрования контента, вычисления хэш-функций и кодов аутентификации сообщения, оценивания цифровых подписей и/или т.п. Память 204 также обычно включает в себя защищенный контент 228 и соответствующие лицензии 229, а также криптографические ключи, сертификаты и т.п. (не показаны).
Специалисту в данной области техники очевидно, что описанные здесь системы и способы можно применять на практике с использованием вычислительных устройств, аналогичных или идентичных изображенным на фиг. 2, или с использованием практически любого другого подходящего вычислительного устройства, в том числе вычислительного устройства, которое не обрабатывает некоторые из компонентов, показанных на фиг. 2, и/или вычислительного устройства, которое обрабатывает другие компоненты, которые не показаны. Таким образом, очевидно, что фиг. 2 приведена в целях иллюстрации, но не ограничения.
Здесь описаны механизм управления цифровыми правами и соответствующие системы и способы, которые можно использовать для обеспечения некоторых или всех функций управления правами в системах, например, показанных на фиг. 1 и 2, или в системах других типов. Кроме того, ниже описаны различные другие системы и способы, которые можно использовать в контексте систем, например, показанных на фиг. 1 и 2, а также в других контекстах, в том числе, контекстах, не связанных с управлением цифровыми правами.
2. Архитектура механизма ΏΚΜ.
В одном варианте осуществления, сравнительно простой, открытый и гибкий механизм управления цифровыми правами (ΏΚΜ) используется для реализации базовых функций ΏΚΜ. В предпочтительном варианте осуществления, этот механизм ΏΚΜ должен сравнительно легко интегрироваться в среду вебуслуг, которая, например, описана в заявке '551, и в практически любую среду хоста или архитектуру программного обеспечения. В предпочтительном варианте осуществления, механизм ΏΚΜ не зависит от конкретных медиа-форматов и криптографических протоколов, что дает разработчикам свободу выбора стандартных или собственных технологий в соответствии с конкретной ситуацией. Предпочтительные варианты осуществления механизма ΏΚΜ используют простую модель администрирования, но ее можно использовать для выражения сложных соотношений и бизнес-моделей.
Некоторые иллюстративные варианты осуществления механизма ΏΚΜ, которые описаны ниже, относятся к иллюстративной реализации, именуемой ΟοΙοριίδ; однако очевидно, что настоящее изобретение не ограничивается конкретными деталями иллюстративного Ос!ори8, которые приведены в целях иллюстрации, но не ограничения.
2.1. Обзор.
На фиг. 3 показано, как иллюстративный механизм ΏΚΜ 303а может функционировать в системе 302, которая использует ΏΚΜ.
Согласно фиг. 3, в одном варианте осуществления механизм ΏΚΜ 303 а встроен или интегрирован в приложение хоста 304а (например, приложение представления контента, например, аудио- и/или видеопроигрывателя, приложение представления текста, например, программу электронной почты, текстовый редактор, программу чтения электронных книг или программу чтения документов и/или т.п.) или осуще
- 5 012918 ствляет связь с ним. В одном варианте осуществления, механизм ΌΒΜ 303а осуществляет функции ΌΒΜ и опирается на приложение хоста 304а на предмет таких услуг, как шифрование, дешифрование, управление файлами и/или других функций, которые хост может обеспечивать более эффективно. Например, в предпочтительном варианте осуществления, механизм ΌΚΜ 303 а способен манипулировать объектами ΌΚΜ 305, которые содержат лицензию 306 на защищенный контент 308. В некоторых вариантах осуществления, механизм ΌΚΜ 303а также может передавать ключи приложению хоста 304а. Согласно фиг. 3, механизм ΌΒΜ 303а и/или приложение хоста 304а может использовать веб-услуги 305а и/или услуги хоста 306а для обработки и/или информацию, необходимую для решения соответствующих задач. В заявке '551 приведены примеры таких услуг, а также показано, каким образом механизм ΌΒΜ 303а и приложение хоста 304а могут взаимодействовать с ними.
В примере, показанном на фиг. 3, механизм ΌΚΜ 303а, приложение хоста 304а, услуги хоста 306а, и интерфейс веб-услуг 305а загружаются в устройство 300а, например персональный компьютер (ПК) конечного пользователя. Устройство 300а поддерживает связь с сервером 300Ь, от которого поступают контент 308 и лицензия 306, а также с портативным устройством 3006, на которое устройство 300а может пересылать контент 308 и/или лицензию 306. Каждое из этих других устройств может включать в себя механизм ΌΚΜ 303, аналогичный или идентичный механизму ΌΒΜ 300а, который может быть интегрирован в конкретное приложение хоста и среду хоста устройства. Например, сервер 300Ь может включать в себя приложение хоста 304Ь, которое осуществляет массовую упаковку контента и/или лицензий и использует механизм ΌΒΜ 300а для оценивания объектов управления, связанных с упаковываемым контентом, для согласования с любыми ограничениями на повторное распространение. Аналогично, устройство 300с может включать в себя приложение хоста 304с, способное представлять и упаковывать контент, тогда как устройство 300а может включать в себя приложение хоста, способное просто представлять контент. В порядке еще одного примера возможного разнообразия сред хоста, устройство 3006 может не включать в себя интерфейс веб-услуг, но, вместо этого, может опираться на связь с устройством 300а и интерфейс веб-услуг 305а постольку, поскольку приложение хоста 3046 и/или механизм ΌΚΜ 3036 требуют использования каких-либо веб-услуг. На фиг. 3 показан только один пример системы, в которой можно использовать механизм ΌΚΜ; очевидно, что описанные здесь варианты осуществления механизмов ΌΚΜ можно реализовать и объединять с приложениями и системами самыми разнообразными способами, не ограничиваясь иллюстративными примерами, показанными на фиг. 3.
2.2. Объекты.
В предпочтительных вариантах осуществления, объекты защиты и администрирования контента используются для представления сущностей в системе, для защиты контента, для связывания правил пользования с контентом и для определения, можно ли предоставить запрошенный доступ.
Как описано более подробно ниже, в одном варианте осуществления, используются следующие объекты:
| Тип объекта | Функция |
| Νοάβ (узел) | Представляет сущности |
| Ыпк (связь) | Представляет направленное соотношение |
| между сущностями | |
| СопСепЪ (контент) | Представляет контент (например, медиа- |
| контент) | |
| СопбепбКеу (ключ | Представляет ключи шифрования, |
| контента) СопСго! (объект | используемые для шифрования контента Представляет правила пользования, |
| управления) | которые регламентируют взаимодействие |
| с контентом | |
| СопргоИег | Представляет связи между объектами |
| (контроллер) | СопЬго1 и СопбепЪКеу |
| РгоЪесРог | Представляет связи между объектами |
| (протектор) | СопЪепЕ и СопРепРКеу |
2.2.1. Объекты «узел».
Объекты «узел» используются для представления сущностей в системе. На практике, узел обычно представляет пользователя, устройство или группу. С объектами «узел» также обычно связаны атрибуты, которые представляют определенные свойства сущности, связанной с узлом.
Например, на фиг. 4 показаны два пользователя (Ксан 400 и Нокс 402), два устройства (ПК 404 и портативное устройство 406), и несколько сущностей, которые представляют группы (например, членов семьи Кери 408, абонентов публичной библиотеки 410, подписчиков на конкретные музыкальные услуги
- 6 012918
412, устройств 414, одобренных ΚΙΛΆ (Американской ассоциацией звукозаписывающих компаний), и устройств 416, изготовленных конкретной компанией), с каждой из которых связан объект «узел».
В одном варианте осуществления объекты «узел» включают в себя атрибуты, указывающие, что представляет узел. Один пример атрибута это тип узла. Помимо представления пользователей, групп или устройств, атрибут «тип узла» можно использовать для представления других сущностей. В некоторых вариантах осуществления, объект «узел» также может включать в себя информацию криптографического ключа, например, при использовании варианта осуществления методов вывода и распространения ключа, описанных здесь в другом месте.
В некоторых вариантах осуществления, объекты «узел» также включают в себя пару асимметричных ключей конфиденциальности, которая используется для «нацеливания» конфиденциальной информации на подсистемы, имеющие доступ к конфиденциальным частям объекта «узел». Это может быть сущность, которую представляет узел (например, Музыкальные услуги 412) или некоторая сущность, отвечающая за управление узлом (например, конечный пользователь (например, Нокс 402) может отвечать за управление своим портативным устройством 406).
2.2.2. Объекты «связь».
В предпочтительном варианте осуществления, объекты «связь» представляют собой подписываемые объекты, используемые для показа соотношения между двумя узлами. Например, согласно фиг. 4, связь 418 от узла ПК 404 к узлу Нокс 402 показывает право собственности. Связь от узла Нокс 402 к узлу «семья Кери» 408 показывает принадлежность, как и связь от узла «семья Кери» 408 к узлу «подписчики на музыкальные услуги» 412. В одном варианте осуществления, объекты «связь» выражают соотношение между двумя узлами, и, таким образом, соотношения, показанные на фиг. 4, можно представить с использованием десяти связей.
Согласно фиг. 4, граф 420 можно использовать для выражения соотношения между узлами, где объекты «связь» являются ориентированными ребрами между узлами. Например, на фиг. 4, соотношение между узлом «семья Кери» 408 и узлом «музыкальные услуги» 412 указывает, что существует ориентированное ребро 422 в графе, вершинами которого являются узел «семья Кери» 408 и узел «музыкальные услуги» 412. Нокс 402 и Ксан 400 являются членами семьи Кери 408. Поскольку Нокс 402 связан с семьей Кери 408, и семья Кери 4 08 связана с Музыкальными услугами 412, должен быть путь между Ноксом 402 и Музыкальными услугами 412. Механизм ΌΚΜ рассматривает узел как доступный из другого узла, когда существует путь от этого узла к другому узлу. Это позволяет записать управляющий элемент, который позволяет разрешать доступ к защищенному контенту на основании того условия, что узел доступен из устройства, на котором выполняется приложение, которое запрашивает доступ к защищенному контенту.
Как описано более подробно ниже, объекты «связь» также могут, в необязательном порядке, содержать некоторые криптографические данные, которые позволяют выводить ключи контента. Объекты «связь» также могут содержать программы управления, которые задают условия, при которых связь можно считать действительной. Такие программы управления могут выполняться или интерпретироваться (эти термины используются здесь взаимозаменяемо) виртуальной машиной механизма ΌΚΜ для оценивания действительности связи (например, для определения, можно ли использовать связь для достижения данного узла в графе авторизации).
В одном варианте осуществления, связи являются подписываемыми. Можно использовать любой подходящий механизм цифровой подписи, и в одном варианте осуществления механизм ΌΚΜ не задает, как подписываются объекты «связь», и не оценивает никакие соответствующие сертификаты, вместо этого, он опирается на систему хоста для проверки любых таких подписей и/или сертификатов. Это позволяет архитектору или администратору системы задавать срок действия объекта «связь», отменять его и т. д. (например, с использованием истечения срока действия, отмены и/или т. п. ключей или сертификатов), тем самым обеспечивая дополнительный уровень управления политикой и безопасности на вершине управления политикой и безопасности, обеспечиваемых оцениванием программ управления и объектов ΌΚΜ механизмом ΌΚΜ в контексте конкретных фрагментов защищенного контента и/или связей (например, истечение срока действия связи можно, альтернативно или дополнительно, реализовать путем включения соответствующей программы управления в сам объект «связь», которая, при выполнении, будет применять дату окончания срока действия или другой период действия). В одном варианте осуществления, механизм ΌΚΜ является общим и работает с любой подходящей схемой шифрования, цифровой подписи, отмены и/или другой схемой безопасности, которая используется приложением и/или средой хоста. Таким образом, например, если механизму ΌΚΜ нужно определить, имеет ли конкретная связь надлежащую подпись, он может просто вызвать приложение хоста (и/или криптографическую службу хоста или системы) для проверки подписи в соответствии с конкретной схемой подписи, выбранной проектировщиком системы, детали которой могут быть неизвестны механизму ΌΚΜ. В других вариантах осуществления, механизм ΌΚΜ сам осуществляет фактическое оценивание подписи, с опорой на хост, просто для указания использования надлежащего алгоритма подписи.
2.2.3. Защита и администрирование контента.
Согласно фиг. 3, в типичном случае, поставщик контента 300Ь использует приложение 304Ь, кото
- 7 012918 рое включает в себя механизм упаковки для шифрования или иной криптографической защиты фрагмента электронного контента 308, и создает лицензию 306, которая регламентирует доступ к этому контенту или другое его использование. В одном варианте осуществления, лицензия 308 содержит набор объектов 305, которые указывают, как можно использовать контент 308, а также включает в себя ключ(и) шифрования контента и/или информацию, необходимую для его(их) получения. В одном варианте осуществления, контент 308 и лицензия 306 логически разделены, но связаны друг с другом внутренними ссылками (например, с использованием ΙΌ объекта 310). Во многих случаях, удобно сохранять и/или доставлять контент и лицензию совместно; однако в предпочтительных вариантах осуществления это не требуется. В одном варианте осуществления, лицензию можно применять к более чем одному элементу контента, и более чем одну лицензию можно применять к любому отдельно взятому элементу контента.
Согласно фиг. 3, когда приложение хоста 304а, выполняющееся на клиентском устройстве 300а, хочет осуществить действие на конкретном фрагменте контента 308, оно просит механизм ΌΒΜ 303а проверить, разрешено ли действие, которое оно намеревается совершить (например, воспроизведение). В одном варианте осуществления, механизм ΌΚΜ 303а, из информации, содержащейся в объектах 305, содержащих лицензию контента 306, загружает и выполняет программу управления, связанную с контентом 308, и разрешение на осуществление действия дается или не дается на основании результата, возвращенного программой управления. Для дачи разрешения обычно требуется выполнение некоторых условий, например, условия доступности узла из узла, представляющего запрашивающую(ее) сущность/устройство 300а.
На фиг. 5 показана логическая блок-схема, демонстрирующая, как механизм ΌΚΜ, согласно варианту осуществления, может определять, авторизовано ли запрошенное действие (например, просмотр фрагмента контента). Согласно фиг. 5, принимается (500) запрос на оценивание лицензии на данное действие. Например, этот запрос может поступать от приложения хоста, после того, как хост принимает от пользователя запрос на осуществление указанного действия. Согласно фиг. 5, механизм ΌΚΜ оценивает указанную лицензию (502) и определяет, авторизовано ли запрошенное действие (504). Например, лицензия может содержать программу управления, которую выполняет механизм ΌΚΜ, выход которой используется для принятия решения на авторизацию. Если лицензия авторизует запрошенное действие (т.е. на выходе да блока 504), то механизм ΌΚΜ указывает приложению хоста, что запрос удовлетворен (506). В противном случае, механизм ΌΚΜ указывает приложению хоста, что запрос отклонен (508). В некоторых вариантах осуществления, механизм ΌΚΜ может также возвращать приложению хоста различные метаданные, которые, например, связывают условия с предоставлением авторизации (например, обязательства и/или обратные вызовы) или обеспечивают дополнительную информацию, касающуюся причины отказа в авторизации. Например, механизм ΌΚΜ может указать, что запрошенное действие разрешено только, если приложение хоста регистрирует определенную информацию, относящуюся к осуществлению запрошенного действия, или при условии, что приложение хоста осуществляет обратные вызовы механизма ΌΚΜ с заранее заданными интервалами времени, например, для повторного оценивания лицензии. Дополнительная информация о таких обязательствах, обратных вызовах, и другие метаданные, возвращаемые механизмом ΌΚΜ, описаны ниже. Если запрошенное действие авторизовано, ключ контента извлекается (например, из объекта Соп1еп1Кеу лицензии) и используется для отпуска контента для запрашиваемого использования.
2.2.4. Объекты ΌΒΜ лицензии.
Согласно фиг. 6, в предпочтительном варианте осуществления лицензия 600 представляет собой совокупность объектов. В примере, показанном на фиг. 6, лицензия 600 содержит объект Соп1еп1Кеу 602, объект «протектор» 604, объект «контороллер» 606, и объект управления 608. Согласно фиг. 6, объект Соп1еп1Кеу 602 включает в себя зашифрованные данные ключа 610 (например, зашифрованную версию ключа, необходимого для дешифрования зашифрованного элемента контента 612) и информацию, относящуюся к криптосистеме, используемой для шифрования данных ключа. Объект «протектор» 604 связывает объект Соп1еп1Кеу 602 с одним или несколькими объектами «контент» 614. Согласно фиг. 6, объект управления 608 включает в себя и защищает программу управления 616, которая указывает, как регламентируется объект «контент» 614. В предпочтительном варианте осуществления, программа управления 616 является фрагментом исполнимого байт-кода, который выполняется на виртуальной машине, используемой механизмом ΌΚΜ. Программа управления определяет, можно ли осуществлять определенные действия на контенте, проверяя выполнение условий, указанных в программе управления, например, доступны ли определенные узлы с использованием действительных объектов «связь», сохранены ли определенные объекты состояния, имеет ли среда хоста определенные характеристики, и/или т.п. Согласно фиг. 6, объект «контроллер» 606 используется для связывания одного или нескольких объектов Соп1еп1Кеу 602 с объектом управления 608.
Лицензия 600 также может содержать дополнительные объекты, например, метаданные, обеспечивающие описание, считываемое машиной или человеком, условий доступа к контенту, требуемых лицензией. Альтернативно или дополнительно, такие метаданные могут быть включены в качестве расширения ресурсов одного из других объектов (например, объекта управления 608). Согласно варианту осуществления, показанному на фиг. 6, объект управления 608 и объект «контроллер» 606 являются подписы
- 8 012918 ваемыми, что позволяет системе удостовериться в том, что информация управления поступила из доверенного источника, прежде чем использовать ее для принятия решений относительно доступа к контенту. В одном варианте осуществления, действительность объекта управления 608 также можно проверять путем проверки защищенного хэша, включенного в объект «контроллер» 606. Объект «контроллер» 606 также может содержать значение хэша для каждого из ключей или других данных ключа, содержащихся в объекте(ах) СоШсШКсу 602, на который(е) он ссылается, благодаря чему нарушителю довольно трудно подделать его представление путем установления связи между данными ключа и объектом СоШсШКсу.
Согласно фиг. 6, в одном варианте осуществления контент 612 зашифрован и включен в объект «контент» 614. Используемый ключ дешифрования 610 включен в объект СоШсШКсу 602 (или представлен им), и связь между ними представлена объектом «протектор» 604. Согласно фиг. 6, уникальные ГО используются для облегчения установлению связи объектом «контент» 614 и объектом СоШсШКсу 602. Правила, которые регламентируют использование ключа 610 для дешифрования контента 612, включены в объект управления 608, и связь между объектом управления 608 и объектом Соп1сп1Ксу 602 представлена объектом «контроллер» 606, опять же, с использованием уникальных ГО.
Очевидно, что, хотя на фиг. 6 показаны объекты, содержащие лицензию в одном предпочтительном варианте осуществления, описанные здесь системы и способы ΌΒΜ не ограничиваются использованием этой структуры лицензии. Например, без ограничения, можно использовать лицензии, в которых функции различных объектов, показанных на фиг. 6, объединены в меньшее количество объектов, или распределены по дополнительным объектам, или разбиты между объектами иным образом. Альтернативно или дополнительно, варианты осуществления описанных здесь систем и способов можно применять на практике с лицензиями, которым недостает некоторых функций, обеспечиваемых структурой лицензии, показанной на фиг. 6, и/или, в которых предусмотрены дополнительные функции. Таким образом, очевидно, что можно использовать любой подходящий механизм для связывания лицензий с контентом в соответствии с описанными здесь принципами, хотя в предпочтительных вариантах осуществления используется преимущественная структура, показанная на фиг. 6.
2.3. База данных состояний.
В одном варианте осуществления, механизм ΌΚΜ включает в себя защищенное постоянное хранилище объектов, или имеет доступ к нему, которое можно использовать для обеспечения механизма защищенного хранилища состояний. Такое приспособление полезно для обеспечения программ управления, способных считывать и записывать информацию состояния, которая сохраняется от вызова к вызову. Такую базу данных состояний можно использовать для сохранения объектов состояния, например счетчиков воспроизведения, даты первого использования, совокупного времени представления и/или т.п., а также состояния принадлежности и/или любых других пригодных данных. В некоторых вариантах осуществления, механизм ΌΚΜ, выполняющийся на первой системе, может не иметь доступа к локальной базе данных состояний, и может иметь возможность обращаться к удаленной базе данных состояний, например, с использованием веб-услуг и/или услуг хоста. В ряде случаев, механизму ΌΚΜ, выполняющемуся на первой системе, может понадобиться доступ к информации состояния, хранящейся в базе данных на удаленной системе. Например, первая система может не включать в себя базу данных состояний, или может не иметь информации, в которой она нуждается, в своей собственной базе данных состояний. В некоторых вариантах осуществления, когда механизм ΌΚΜ сталкивается с подобной ситуацией, он может обращаться к удаленной базе данных состояний через интерфейс услуг, и/или с использованием программ-агентов, что описано более подробно ниже.
2.4. О программах управления.
Описанные здесь системы и способы используют программы управления в различных контекстах. Например, программы управления, содержащиеся в объектах управления, можно использовать для выражения правил и условий, регламентирующих использование защищенного контента. Кроме того, программы управления в объектах «связь» можно использовать для выражения правил и условий, используемых для определения, пригодна ли связь для данной цели (например, анализа доступности узла). Такие программы управления иногда называются здесь ограничениями по связи. Еще один контекст, в котором можно использовать программы управления, это объекты «агент» или «делегат», где код управления используется для осуществления действия от имени другой сущности (в случае агентских программ управления) или от имени другого объекта управления (в случае делегатских программ управления).
В одном варианте осуществления, программы управления выполняются или интерпретируются виртуальной машиной, базирующейся на механизме ΌΚΜ, а не выполняющейся непосредственно физическим процессором. Однако очевидно, что можно легко построить физический процессор или иное логическое устройство для выполнения программ управления. В одном варианте осуществления, программы управления имеют формат байт-кода, что дает дополнительную возможность взаимодействия между платформами.
В предпочтительном варианте осуществления, программы управления написаны на языке ассемблера и преобразованы в байт-код программой ассемблера. В других вариантах осуществления можно использовать шаблоны и/или языки выражения прав высокого уровня для обеспечения начального выражения прав, правил и/или условий, и можно использовать компилятор для преобразования выражения
- 9 012918 высокого уровня в байт-код для выполнения механизмом ΌΚΜ согласно описанному здесь варианту осуществления. Например, выражения прав, записанные в собственном формате ΌΚΜ, можно, с помощью соответствующего компилятора, преобразовать или транслировать в функционально эквивалентное выражение на уровне байт-кода для выполнения на механизме ΌΚΜ согласно описанному здесь варианту осуществления, что позволяет использовать защищенный фрагмент контента, в соответствии с условиями, указанными поставщиком контента, на системах, которые понимают собственный формат ΌΚΜ, а также системах, которые включают в себя механизм ΌΚΜ, например, описанный здесь. Также очевидно, что описанные здесь системы и способы на основе механизма управления цифровыми правами не ограничиваются использованием выражений прав в формате байт-кода, интерпретируемых виртуальной машиной. Напротив, в некоторых вариантах осуществления, права можно выражать любым подходящим способом (например, с использованием языка выражения прав высокого уровня (КЕЬ), шаблона, и т.д.), и граф авторизации и/или другие описанные здесь методы, осуществляемые с использованием прикладной программы, предназначенной для распознавания и оценивания таких выражений прав.
2.4.1. Условия.
Как указано выше, программы управления обычно выражают одно или несколько условий, которые должны выполняться для удовлетворения запроса на использование фрагмента контента, для того, чтобы связь была признана действительной, и/или т.п. Можно использовать любые подходящие условия, в зависимости от требований поставщика контента или архитектора системы, и/или функций, обеспечиваемых системой.
В предпочтительных вариантах осуществления, виртуальная машина, используемая механизмом ΌΚΜ, поддерживает программы любой сложности, которые способны проверять выполнение условий, например некоторые или все из следующих:
Условия на основе времени: сравнение значения времени клиента со значением или значениями, указанным(и) в программе управления.
Нацеливание конкретного узла: проверка, доступен ли определенный узел из другого узла. Эта концепция обеспечивает поддержку таких моделей, как домены, подписки, отношения принадлежности и т. п.
Проверка, совпадают ли атрибуты определенного узла с указанными значениями: проверка любых атрибутов узла, например, удовлетворяют ли возможности представления устройства, связанного с узлом, требованиям верности.
Проверка, обновлены ли метаданные, связанные с безопасностью, на клиенте: проверка, например, имеет ли клиент приемлемую версию клиентского программного обеспечения, и точное измерение времени. В некотором варианте осуществления, такая проверка может опираться, например, на утверждения в одном или нескольких сертификатах от службы сертификации данных.
Условия на основе состояния: проверка информации в базе данных состояний. Например, база данных состояний может содержать информацию, сгенерированную в результате предыдущего выполнения программ управления, и/или жетоны, свидетельствующие о владении подписками, принадлежности и/или т.п., что позволяет оценивать условия, определяемые счетчиками (например, количество актов воспроизведения, количество актов экспорта, пределы истекшего времени и т.д.) и другую информацию, относящуюся к зарегистрированным событиям и условиям.
Характеристики среды. Например, проверка, имеет ли оборудование и/или программное обеспечение в среде хоста определенные характеристики, например, способность распознавать и применять обязательства; проверка наличия или отсутствия определенных программных или аппаратных компонентов, например, защищенного выходного канала; проверка информации близости, например, близости запрашивающего устройства к другому устройству или приложению; проверка характеристик удаленных систем и/или хранящихся в них данных, с использованием сетевых услуг и/или агентов; и/или т.п.
С использованием этих или любых других подходящих условий, объект управления может выражать правила, которые регламентируют представление, перенос, экспорт и/или т.п. контента. Очевидно, что вышеприведенный список условий носит иллюстративный характер, и что можно задать и использовать любые подходящие условия, например, путем реализации системного вызова для использования при проверке выполнения нужного условия. Например, без ограничения, если желательно потребовать, чтобы устройство находилось в конкретной подсети, можно задать системный вызов (например, СеНРСоийд), который способен возвращать информацию 1РСоийд устройства хоста (или информацию ГРСоийд удаленного устройства, если системный вызов запущен на удаленном устройстве с использованием агента), который может использовать программа управления для проверки, находится ли устройство в предписанной подсети.
2.4.2. Агенты.
Предпочтительные варианты осуществления описанных здесь систем и способов на основе механизма ΌΚΜ обеспечивают поддержку независимых объектов, несущих программы управления. Такие агенты могут распространяться на механизм ΌΚΜ, выполняющийся на удаленной системе, для выполнения указанных функций, например, записи в защищенное хранилище состояний удаленного механизма ΌΚΜ. Например, агент может передаваться вследствие контакта с удаленной службой или выполнения
- 10 012918 удаленной программы управления. Агент также можно использовать для осуществления операции перемещения контента, для инициализации счетчика, для отмены регистрации узла и/или т.п. В порядке еще одного примера, агент можно использовать для осуществления анализа доступности из удаленного узла к другому узлу. Такой агент, например, может быть полезен при применении политики, запрещающей второму пользователю регистрировать устройство, зарегистрированное первым пользователем. Если второй пользователь запросил регистрацию, агент может быть направлен на устройство вторым пользователем или службой регистрации, действующей от его имени, для определения, было ли устройство ранее зарегистрировано для первого пользователя, в каковом случае запрос второго пользователя на регистрацию будет отклонен.
На фиг. 7А и 7В показано использование агентов в одном варианте осуществления. Согласно фиг. 7 А, предположим, что две сущности - система А 700 и система В 702 - желают связаться друг с другом через компьютерную сеть 703, и что используется система ΌΒΜ, способная описывать и применять правила для определенных операций, например, доступа к защищенному контенту или создания объектов ΌΚΜ, которые можно использовать для представления отношений принадлежности, состояния регистрации и/или т.п. в ряде случаев, правило(а) оцениваются на системе А 700, но для этого требуется информация, которая зависит от состояния системы В 702. Система ΌΚΜ 704, которая применяет правило (а) на системе А 700, должна доверять этой информации.
Например, система ΌΚΜ 704 на системе А 700 может оценивать/применять правило осуществления дистанционного представления контента из системы А 700 в системе В 702, и правило может указывать, что такая операция разрешена только, если система В 702 входит в состав определенной группы устройств, причем принадлежность к этой группе подтверждается наличием объекта «состояние» 711 в защищенной базе данных состояний 716, доступной на системе В 702.
Способ, используемый в предпочтительном варианте осуществления для работы в таких ситуациях, использует агенты. Например, если системе А 700 нужна информация из системы В 702, система А 700 подготавливает агент 705, который, в одном варианте осуществления, является программой управления (например, последовательностью команд, которые могут выполняться механизмом ΌΚΜ), которая передается из системы А 700 в систему В 702. В одном варианте осуществления, система А 700 передает агентский код 705 в систему В 702 по аутентифицированному каналу связи 720, благодаря чему система А 700 может быть уверена, что агент 705 будет выполняться именно в системе В 702. В некоторых вариантах осуществления, помимо агентского кода 705, система А 700 также может передавать системе В 702 один или несколько параметров, которые агентский код 705 может использовать для осуществления своей работы.
Согласно фиг. 7В, система В 702 принимает агент 705 и любые параметры, связанные с агентом, и запускает агентский код 705. Когда агент 705 выполняется на системе В 702, он обращается к базе данных состояний 716 системы В, извлекает информацию состояния 711 и/или осуществляет одно или несколько вычислений над ней, и передает результаты 713 обратно в систему А 700, предпочтительно по аутентифицированному каналу связи 710, благодаря этому, система А 700 имеет информацию, которая ей нужна для продолжения своего оценивания.
2.4.3. Ограничения по связи.
В одном варианте осуществления, набор процедур, которые представляют правила, регламентирующие осуществление определенной операции (например воспроизведение) на элементе контента, называется управляющий элемент действия. Набор процедур, которые представляют ограничения по действительности на объекте «связь» называется ограничение по связи. Наподобие управляющих элементов действия, в предпочтительных вариантах осуществления ограничения по связи могут выражать любую подходящую комбинацию условий. Также аналогично управляющим элементам действия, ограничения по связи можно оценивать локально и/или дистанционно с использованием интерфейса услуг или агента.
2.4.4. Обязательства и обратные вызовы.
В одном варианте осуществления, определенные действия, когда они разрешены, требуют дополнительного участия приложения хоста. Обязательства представляют операции, которые должно осуществлять приложение хоста после использования ключа контента, которые они запрашивают. Обратные вызовы представляют вызовы одной или нескольких процедур программы управления, которые должно осуществлять приложение хоста после использования ключа контента, которые они запрашивают. Примеры обязательств включают в себя, без ограничения, требование, чтобы определенные выходы и/или управляющие элементы были отключены в ходе представления контента (например, для предотвращения записи контента в незащищенный выход или для предотвращения перемотки вперед определенных важных сегментов контента); требование, чтобы информация, относящаяся к использованию контента записывалась (например, информация измерения или аудита) и/или передавалась в удаленное место (например, в расчетный центр, поставщику услуг и т.п.); требование, чтобы программа-агент выполнялась локально или дистанционно; и/или т.п. Примеры обратных вызовов включают в себя, без ограничения требование, чтобы хост осуществлял обратный вызов программы управления в определенное абсолютное время, по истечении определенного времени (например, времени пользования контентом), по наступле
- 11 012918 нии определенного события (например, по завершении периода пробного представления контента), когда использование контента остановлено, и/или т.п. Например, обратный вызов по истечении определенного времени можно использовать для увеличения или уменьшения бюджетов, счетчиков воспроизведения и т.п. (например, дебетования бюджета пользователей только, если они используют фрагмент контента в течение, по меньшей мере, определенного времени), что защищает пользователя от списания с его лицевого счета в случае, если он непреднамеренного нажмет кнопку воспроизведения, но сразу же нажмет кнопку остановки.
В одном варианте осуществления, существуют разные типы обязательств и обратных вызовов, и если приложение сталкивается с каким-либо критическим обязательством или обратным вызовом, которое(ый) он не поддерживает или не понимает (например, потому, что тип обязательства был задан после реализации приложения), приложение должно отказаться от продолжения действия, для которого было возвращено это(т) обязательство или параметр обратного вызова.
2.4.5. Пример.
На фиг. 8-12 показан пример того, как иллюстративный вариант осуществления механизма ΌΚΜ может управлять использованием фрагмента контента. Согласно фиг. 8, предположим, что механизм ΌΚΜ принял запрос на воспроизведение группы 800 элементов контента 802, 804. Например, элементы контента 802, 804 могут содержать разные подчасти мультимедиа-представления, различные треки альбома, различные фрагменты контента, полученные от службы подписки, вложенные файлы электронной почты и т.п. Запрос может приниматься механизмом ΌΚΜ от приложения хоста, которое, в свою очередь, приняло запрос от пользователя вычислительного устройства, после чего приложение хоста было выполнено. Запрос от приложения хоста обычно идентифицирует запрошенное действие, фрагмент или фрагменты контента, после которых должно быть выполнено действие, и лицензию(и), которая(ые) управляют контентом. Механизм ΌΚΜ выполняет процесс, показанный на фиг. 5, для определения, нужно ли удовлетворить запрос.
На фиг. 8 и 9 обеспечен более подробный неограничительный пример процесса, показанного на фиг. 5. Согласно фиг. 9, после приема запроса на доступ к элементам контента 802 и 804 (блок 900), механизм ΌΚΜ проверяет лицензию(и), указанные в запросе, или иначе связанную(ые) с ним, чтобы определить, существует ли действительная лицензия. Например, механизм ΌΚΜ может сначала идентифицировать объекты «протектор» 806 и 808, которые содержат уникальные идентификаторы элементов контента 802 и 804 (т.е. N8:007 и N8:008, соответственно) (блок 902 на фиг. 9). Затем, механизм ΌΚΜ обнаруживает объекты СойейКеу 810 и 812, указанные в объектах «протектор» 806 и 808 (блок 904 на фиг. 9), что, в свою очередь, позволяет механизму ΌΚΜ идентифицировать контроллер 814, который ссылается на оба объекта Сои1еи1Кеу 810 и 812 (блок 906 на фиг. 9). В предпочтительном варианте осуществления, контроллер 814 подписан, и механизм ΌΚΜ проверяет его подпись (или запрашивает услуги хоста для ее проверки). Механизм ΌΚΜ использует контроллер 814 для идентификации объекта управления 816, который регламентирует использование объекты Сои1еи1Кеу 810 и 812 (и, таким образом, элементы контента 802 и 804) (блок 908 на фиг. 9). В предпочтительном варианте осуществления, механизм ΌΚΜ проверяет целостность объекта управления 816 (например, путем вычисления дайджеста объекта управления 816 и сравнения его с дайджестом, содержащимся в контроллере 814). Если проверка целостности успешна, механизм ΌΚΜ выполняет код управления, содержащийся в объекте управления 816 (блок 910), и возвращает результат (блок 912) приложению хоста, которое использует его для удовлетворения или отклонения запроса пользователя на доступ к контенту. Результат кода управления также может, в необязательном порядке, указывать одно или несколько обязательств или обратных вызовов, которые понадобиться выполнить приложению хоста.
На фиг. 10 показан более подробный пример того, как механизм ΌΚΜ может осуществлять действия, указанные в блоках 910 и 912 на фиг. 9 (т.е. выполнять программу управления и возвращать результат). Согласно фиг. 10, идентифицировав соответствующий объект управления, механизм ΌΚΜ загружает байт-код, содержащийся в объекте управления, в виртуальную машину, которая, предпочтительно, базируется на механизме ΌΚΜ (блок 1000). Механизм ΌΚΜ и/или виртуальная машина также обычно инициализирует среду выполнения виртуальной машины (блок 1002). Например, виртуальная машина может выделять память, необходимую для выполнения программы управления, инициализировать регистры и другие переменные среды, и/или получать информацию о среде хоста, в которой действует виртуальная машина (например, делая вызов 8у51ет.Но51.Се1ОЬ)ес1. описанный ниже). Очевидно, что в некоторых вариантах осуществления блоки 1000 и 1002 можно эффективно комбинировать или перемежать и/или обращать их порядок. Согласно фиг. 10, виртуальная машина затем выполняет байт-код программы управления (блок 1004). Как описано здесь в другом месте, для этого можно делать вызовы кода другой виртуальной машины, извлекать информацию состояния из защищенного хранилища и/или т.п. По окончании выполнения программы управления, она обеспечивает выход (например, в предпочтительном варианте осуществления, Ех1еибеб81а1и&В1оск), который может использовать, например, вызывающее приложение для определения, был ли удовлетворен запрос, и, если это так, связаны ли с ним какие-либо обязательства или обратные вызовы; был ли отклонен запрос, и, если это так, по какой причине; или произошли ли какие-либо ошибки в ходе выполнения (блок 1006).
- 12 012918
Как указано выше, код управления, содержащийся в объекте управления 816, указывает условия или другие требования, которые должны быть выполнены для осуществления запрошенного использования элементов контента 802 и 804. Описанные здесь системы и способы позволяют задавать наборы условий любой сложности; однако, в целях этого примера, предположим, что программа управления призвана требовать, чтобы, для воспроизведения элементов контента 802 и 804, (а) данный узел пользователя был доступен из устройства, на котором был сделан запрос на воспроизведение контента, и (Ь) текущая дата была позже указанной даты.
На фиг. 11 показано, как иллюстративный вариант осуществления механизма ΌΚΜ 1100, выполняющийся на устройстве 1102, может выполнять вышеописанную иллюстративную программу управления, и на фиг. 12 показана логическая блок-схема этапов, предусмотренных при выполнении процесса. Согласно фиг. 11, механизм ΌΚΜ 1100 создает контекст выполнения виртуальной машины (например, путем вызова 8у51ет.Но51.8ратепУт) 1104 и загружает программу управления. Виртуальная машина 1104 начинает выполнение программы управления в точке входа, указанной механизмом ΌΚΜ 1100 (например, в положении процедуры Соп1го1.Лс1юп5.Р1ау.регГопп). В этом примере, программа управления нуждается в определении, доступен ли данный узел из узла индивидуальных особенностей устройства 1102, на котором выполняется механизм ΌΚΜ 1100. Чтобы произвести такое определение, программа управления вызывает 1105 услугу менеджера связей 1106, предоставляемую механизмом ΌΚΜ 1100, указывая узел, с которым требуется установить связь (блок 1200 на фиг. 12). Менеджер связей 1106 отвечает за оценивание объектов «связь» для определения, доступен ли один узел из другого. Чтобы делать это эффективно, менеджер связей 1106 может предварительно вычислять, существует ли путь от узла индивидуальных особенностей 1110 устройства 1102 к различным узлам 1114, указанным в любых объектах «связь», которыми обладает это устройство 1102. Таким образом, менеджер связей 1106 может, просто проверяя поля к и от связей, к которым он обращается, определять, какие узлы потенциально доступны из узла индивидуальных особенностей 1110 устройства 1102. Когда менеджер связей 1106 принимает вызов 1105 от виртуальной машины 1104, он определяет, доступен ли указанный узел 1112, сначала определяя, существует ли путь от узла индивидуальных особенностей 1110 к указанному узлу 1112 (например, проверяя ΙΌ узла в списке узлов, которые ранее были определены как теоретически доступные) (блок 1202 на фиг. 12). Если путь существует, менеджер связей 1106 оценивает любые программы управления, содержащиеся в связях, чтобы определить, действительны ли связи (блоки 1204-1210 на фиг. 12). Чтобы оценить программы управления в объектах «связь» (блок 1206 на фиг. 12), менеджер связей 1106 может использовать свою собственную виртуальную машину 1108, на которой он выполняет программы управления, включенные в объекты «связь». Менеджер связей 1106 возвращает результаты своего определения (т. е. доступен ли данный узел) программе управления, выполняющейся на виртуальной машине 1104, где она используется для общего оценивания, будет ли удовлетворен запрос на воспроизведение фрагмента контента. После определения, что указанный узел 1112 доступен из узла индивидуальных особенностей 1110 устройства 1102, программа управления, выполняющаяся на виртуальной машине 1104, определяет, выполняется ли указанное ограничение по дате (блок 1212 на фиг. 12). Если ограничение по дате выполнено (т.е. на выходе да из блока 1212), то программа управления возвращает результат, указывающий, что указанные условия выполнены (блок 1214 на фиг. 12); в противном случае, программа управления возвращает результат, указывающий, что указанные условия не выполнены (блок 1216 на фиг. 12).
Пример программы управления, например вышеописанной, показан ниже.
- 13 012918 ; Иллюстративная программа управления ; Эта программа управления проверяет, что узел «пользователь» доступен ; и что дата позже конкретной начальной даты ; и раньше конкретной конечной даты ; Значения извлекаются из атрибутов в программе управления константы .еяи ОЕВиСР1<1КТ8¥8САЕЕ.1 .еци ΕΙΝΟ8Υ8ΕΑΕΕ_ΒΥ_ΝΑΜΕ,2 .еци 8У8ТЕМ_НО8Т_ОЕТ_ОВЗЕСТ_8У8САЕЬ, 3 .еци 8иССЕ88,0 .еци ΕΑΙΕυΚΕ,-1 ;данные .ба1а
Соп1го1Тат§е1Иобе1бАйг1Ьи1еРагЬ:
.Мгпщ Ос1ори8/Соп1го1/АйпЬи1е8/Таг§еЙ4ойе1б Соп1го181агЮаТеА11пЬи1еРа1Ь:
.8ίηη§ Ос1ори5/Соп1го1/АПг1Ьи1ез/81а1Юа1е Соп(го1 ЕгкЮа1еА«г1Ьи1еРа1Ь:
.з1пп§ Ос1ориз/Соп1го1/Айг1Ьи1ез/ЕпбОа1е ТагдеОЧобеИ:
.гегоз 256
81агЮа1е:
.1оп« 0
ЕпсГОа1е:
.1опц -1
1з1ЧобеКеасЬаЫеЕипс1юпИате:
,3ίτίη§ ОсЮриз.Связи. кМобеЯеасЬаЫе
- 14 012918
ИИобеКеасЬаЫеРипсбопИитЬег: .1оп§, О
Се1Т1те81атрРипс11опИате:
·5ΐΐΊпд 8уз1ет.Но5(.Ое1Ьоса1Т1те <Зе1Т1 т е8 (атрр ипсбопИитЬег:
.1оп§ О .собе
СЯоЬа1.ОпЬоа<± ; загрузка глобальных функций ; получить номер системного вызова для ОсФриз.ЬткзЛзМобеКеасйаЫе
ΡΕΙ8Η @ ΙϊΝο беКеасЬаЬ 1 еРипсП опК'атс
ΡυδΗ ΡΙΝΏ_8Υ5ΟΑΕΕ_ΒΥ_ΝΑΜΕ
САБЬ ϋυρ
РО 3II @ΙβΝο беКеаскаЬIерипοιίοηΝитЬег
РОКЕ
ΒΚΝ ОпЬоас1_РаН ; получить номер системного вызова для 8уз1ет.Но5Г.Се1Т1те81атр
РОЗН @Се1Т1теЗ(атрГипс1юпИате
Ρϋ8Η ΕΙΝβ_8Υ8ΟΑΕΕ_ΒΥ_ΝΑΜΕ
САЬЬ ϋυρ
ΡΌ8Η @СеШтеЗ!атрРипсиопИитЬег
РОКЕ
ΒΚΝ ОпБоабЕай ; ок
Ри8Н О
КЕТ
ОпЕоабГаИ:
ризн рлшикЕ
КЕТ
Соп1го1,Ас1юпз.Р1ау.1пк:
; получить значения из атрибутов ; получить конечный узел (гарантированно существует)
Ри8Н 256 ; Ке(итВи££ег8|хе (256 байт)
РВЗН @Таг§е1Ь1обе1б ; Возвращаемое значение
РИЗН @Соп!го1Тагде!\обе1бАипЬи(еРа± ; Имя
ΡΤΙ8Η 0 ; Родитель = корневой контейнер
РиЗН 8У8ТЕМ_НО8Т_ОЕТ_ОВ6ЕСТ_8У8САЬЕ
САТЕ ; получить начальную дату
- 15 012918 ризн 4
РиЗН @8(агЮак
РИЗН @Соп!го18!апОа(еАипЬи1еРа1Ь ризно ризн 8¥8ТЕМ_НОЗТ_СгЕТ_ОВ1ЕСТ_5У8САЬЕ сан.
; получить конечную дату ризн 4
РиЗН @ЕпсЮа1е
РиЗН @Соп1го1Еп6Оа1еАйг1Ьи!еРа111 ризно ризн 8У8ТЕМ_Н08Т_ОЕТ_ОВ1ЕСТ_8УЗСАЕЬ
САП ; КеЩгпВийегЗ^ге (4 байта) ; Возвращаемое значение ; Имя ; Родитель = корневой контейнер ; К.е(итВиНег31ге (4 байта) ; Возвращаемое значение ; Имя ; Родитель = корневой контейнер ; успех ризно ризн зиссЕзз
ЗТОР
Соп1го1.Асйоп5.Р1ау.Рег1огт:
Соп1го1.Ас11оп8.Р1ау.С11еск:
; проверить, что конечный узел доступен
РиЗН ©ТагдеШобеН
ΡΌ3Η @1зНо6еКеасКаЫеРипс1юпКитЬег
РЕЕК
САИ
ΒΚΝ Р1ау_РаИ ; поместить текущее время в стек
Р118Н @Се!Т1те5!атрРипс1юпЬ1итЬег
РЕЕК
САЬЬ ; проверить, что дата раньше конечной даты ПИР ; текущее время
РиЗН @Епс1Оа1с
РЕЕК
8λνΑΡ
СМР
ΒΚΝ Р1ау_ЕаИ ; проверить, что дата позже начальной даты ; текущее время в стеке
РиЗН @31аНОа1е
РЕЕК
СМР
ΒΚΝ НауГай ; успех ризно ризн зиссЕзз
ЗТОР
Р1ау_Рай: ризно ризн ΡΑίΕυκΕ ЗТОР .ехрон О1оЬа1.ОпЬоа6 .ехроН Сон1го1.Ас110пз.Р1ау.1п11 .ехроп Соп1го1.Ас1юпз.Р1ау.СЬеск .ехроН Сопгго1.Ас1юп8.Р]ау.Рег1оггп
- 16 012918
Дополнительный пример программы управления включен в приложение Е.
3. Потребление контента и приложения упаковки.
Ниже приведено более подробное описание иллюстративных вариантов осуществления приложения, которое потребляет ΌΚΜ-защищенный контент (например, медиа-проигрывателя, текстового редактора, почтового клиента и т.д., например приложения 303а, 303с и 3036 на фиг. 3), и приложения упаковки, например, приложения 303Ь, которое упаковывает контент, адресованный потребляющим приложениям.
3.1. Архитектура приложения, потребляющего контент.
Приложение, потребляющее контент, обычно нацелено на доступ к защищенному контенту или может составлять часть приложения общего назначения, которое также осуществляет другие функции, например, упаковки контента. В различных вариантах осуществления, приложение, потребляющее контент, может осуществлять некоторые или все из следующих функций:
обеспечивать интерфейс, посредством которого пользователь может запрашивать доступ к защищенным объектам «контент» и принимать информацию о контенте или информацию ошибки;
управлять взаимодействием с файловой системой;
распознавать формат защищенных объектов «контент»;
запрашивать механизм ΌΚΜ для оценивания лицензии на фрагменты контента, для определения, можно ли дать разрешение на доступ к контенту;
проверять цифровые подписи и выполнять другие криптографические функции общего назначения, в осуществлении которых нуждается механизм ΌΚΜ;
запрашивать механизм ΌΚΜ для обеспечения ключей, необходимых для дешифрования защищенного контента; и/или дешифровать защищенный контент и взаимодействовать со службами медиа-представления для представления контента.
В одном варианте осуществления, механизм клиента ΌΚΜ оценивает лицензии, связанные с контентом, подтверждает или отклоняет разрешение использовать контент и передает ключи дешифрования приложению, потребляющему контент. Механизм клиента ΌΚΜ также может выдавать одно или несколько обязательств и/или обратных вызовов приложению, потребляющему контент, требующих от приложения осуществлять определенные действия вследствие получения доступа к контенту.
На фиг. 13 показаны элементы, составляющие клиентское приложение 1300, потребляющее контент, в одном варианте осуществления. Согласно фиг. 13 приложение хоста 1302 является логическим центральным пунктом клиента. Он отвечает за перенос шаблона взаимодействия между другими модулями, а также взаимодействие с пользователем через пользовательский интерфейс 1304. Приложение хоста 1302 предоставляет набор услуг механизму ΌΚΜ 1306 через интерфейс 1308 услуг хоста. Интерфейс 1308 услуг хоста позволяет механизму ΌΚΜ 1306 получать доступ к данным, администрируемым приложением хоста 1302, а также определенным библиотечным функциям, реализованным приложением хоста 1302. В одном варианте осуществления, интерфейс 1308 услуг хоста является единственным внешним интерфейсом для механизма ΌΚΜ 1306.
В одном варианте осуществления, механизм ΌΚΜ 1306 не взаимодействует напрямую с мультимедийным контентом, администрируемым приложением хоста 1302. Приложение хоста 1302 логически взаимодействует с услугами контента 1310 для осуществления доступа к мультимедийному контенту, и передает механизму ΌΚΜ 1306 только фрагменты данных, которые должен обрабатывать механизм. Другие взаимодействия с контентом осуществляются механизмом медиа-представления 1312. Например, в одном варианте осуществления услуги контента 1310 отвечают за получение контента от медиасерверов и за сохранение и администрирование контента в постоянном хранилище клиента, тогда как механизм медиа-представления 1312 является подсистемой, отвечающей за доступ к мультимедийному контенту и его представление (например, на видео- и/или аудио-выходе). В одном варианте осуществления, механизм медиа-представления 1312 принимает некоторую информацию от механизма ΌΚΜ 1306 (например, ключи дешифрования контента), но, в одном варианте осуществления, механизм ΌΚΜ 1306 взаимодействует с механизмом медиа-представления 1312 не напрямую, но через приложение хоста 1302.
Некоторая информация, необходимая механизму ΌΚΜ 1306, может быть доступна совместно с мультимедийным контентом, и ее можно получать и иметь возможность манипулировать ею посредством услуг контента 1310, однако может возникнуть необходимость получать часть этой информации посредством других услуг, например, услуги персонализации или услуги принадлежности (не показаны).
Согласно варианту осуществления, показанному на фиг. 13, криптографические операции (например, шифрование, проверка подписи, и т.д.) осуществляются блоком криптографических услуг 1314. В одном варианте осуществления, механизм ΌΚΜ 1306 не взаимодействует напрямую с блоком криптографических услуг 1314, но взаимодействует косвенно, через хост 1302 (с использованием интерфейса 1308 услуг хоста), который передает его запросы. Криптографическими услугами 1314 также может пользоваться, например, механизм медиа-представления 1312 для осуществления дешифрования контента.
- 17 012918
Очевидно, что фиг. 13 носит иллюстративный характер, и что в других вариантах осуществления различные компоненты, показанные на фиг. 13, могут быть иначе организованы, объединены, разделены, исключены, и/или могут быть добавлены новые компоненты. Например, без ограничения, логическое разделение функций между механизмом ΌΚΜ и приложением хоста на фиг. 13 просто иллюстрирует один возможный вариант осуществления, и возможны различные практические реализации.
Например, механизм ΌΚΜ может быть полностью или частично объединен с приложением хоста. Таким образом, очевидно, что можно использовать любое пригодное разделение функций между приложением хоста и механизмом ΌΚΜ.
3.2. Архитектура упаковщика.
Ниже приведен пример функций, которые может осуществлять механизм упаковки для приложения хоста, которое упаковывает электронный контент. На практике, приложение упаковки может конкретно предназначаться для упаковки, или составлять часть приложения общего назначения, действующего на пользовательской системе, которое также осуществляет доступ к защищенному контенту (упакованному локально или в другом месте, например, в сети).
В различных вариантах осуществления, упаковывающее приложение хоста может осуществлять некоторые или все из следующих функций:
обеспечивать пользовательский интерфейс, посредством которого можно задавать информацию контента и лицензии;
шифровать контент;
создавать объекты ΌΚΜ, составляющие лицензию; и/или создавать объект «контент», который содержит или ссылается на контент и содержит или ссылается на лицензию.
На фиг. 14 показаны элементы, которые составляют приложение упаковки 1400 в одном варианте осуществления. Механизм упаковки ΌΚΜ 1416 отвечает за упаковку лицензий, например, описанных здесь (например, лицензий, содержащих объекты ΌΚΜ, например, объекты управления, контроллеры, протекторы и т.п.). В некоторых вариантах осуществления, механизм упаковки ΌΚΜ 1416 может также связывать метаданные с лицензией для объяснения, в понятной человеку форме, что делает лицензия.
В одном варианте осуществления, приложение хоста 1402 обеспечивает пользовательский интерфейс 1404 и отвечает за получение информации, например, ссылок на контент и действие(я), которое(ые) пользователь (обычно владелец или поставщик контента) хочет осуществить (например, к кому привязать контент, какие условия пользования контентом включить в лицензию, и т.д.). Пользовательский интерфейс 1404 также может отображать информацию о процессе упаковки, например, текст выпущенной лицензии, и, в случае сбоя, причину сбоя. В некоторых вариантах осуществления, некоторая информация, необходимая приложению хоста 1402, может потребовать использование других услуг, например, услуг аутентификации или авторизации и/или принадлежности через точку доступа к службе (8АР). Таким образом, в некоторых вариантах осуществления, приложение упаковки 1400 и/или приложение хоста 1402 может нуждаться в реализации некоторых или всех из следующих служб:
Услуги медиа-формата 1406. В одном варианте осуществления, этот элемент отвечает за управление операциями медиа-формата, например, перекодирование и упаковку. Он также отвечает за шифрование контента, которое достигается посредством модуля 1408 услуг шифрования контента.
Криптографические услуги общего назначения 1410. В одном варианте осуществления, этот элемент отвечает за выдачу/проверку подписей, а также шифрование/дешифрование некоторых данных. Запросы на такие операции может выдавать точка доступа к службе 1414 или механизм упаковки ΌΚΜ 1416 через интерфейс услуг хоста 1412.
Услуги шифрования контента 1408. В одном варианте осуществления, этот модуль логически отделен от криптографических услуг общего назначения 1410, поскольку он не знает о приложении. Он запускается модулем услуг медиа-формата в момент упаковки контента, с набором ключей, ранее выданных механизмом упаковки ΌΚΜ 1416.
4. Вывод ключа.
Ниже описана система вывода ключа, которая естественным образом согласуется с описанными здесь предпочтительными вариантами осуществления механизма ΌΚΜ и архитектурой системы, и/или которую можно использовать в других контекстах. Некоторые примеры в нижеследующем разделе взяты из иллюстративной реализации предпочтительного варианта осуществления этой системы вывода ключа, известной под названием 8сиЬа.
Дополнительные варианты осуществления описаны в заявке '551.
Согласно фиг. 15, в некоторых вариантах осуществления объекты «связь» 1530а, 1530Ь используются для распространения ключей, помимо своей основной цели - установления соотношений между узлами 1500а, 1500Ь, 1500с. Как описано выше, объект управления может содержать программу управления, которую можно использовать для принятия решения, следует ли удовлетворить запрос на осуществление действия. Для этого, программа управления может проверять, доступен ли конкретный узел через цепь связей. Описанные здесь методы вывода ключа пользуются наличием этой цепи связей для облегчения распространения ключа, что позволяет сделать ключ доступным механизму ΌΚΜ, который
- 18 012918 выполняет программу управления.
В одном иллюстративном варианте осуществления, каждый объект «узел» 1500а, 1500Ь, 1500с в данной конфигурации, которая использует необязательную систему распространения ключей, имеет набор ключей, которые используются для шифрования ключей контента и ключей других узлов. Объекты «связь» 1530а, 1530Ь, созданные для использования в той же конфигурации, содержат некоторые криптографические данные в качестве полезной нагрузки, что позволяет выводить информацию ключей, когда цепи связей обрабатываются механизмом ΌΚΜ.
Благодаря узлам и связям, несущим ключи подобным образом, причем цепь связей 1530а, 1530Ь идет от узла А 1500а к узлу С 1500С, сущность (например, механизм ΌΚΜ клиентского приложение хоста), которая имеет доступ к секретным ключам совместного пользования узла А 1515а, 1525а, также имеет доступ к секретным ключам совместного пользования узла С 1515с, 1525с. Возможность доступа к секретным ключам совместного пользования узла С дает сущности доступ к любому ключу контента, зашифрованному этими ключами.
4.1. Узлы, сущности и ключи.
4.1.1. Сущности.
В одном варианте осуществления системы ΌΚΜ, узлы представляют собой объекты данных, не принимающие активного участия в системе. Активные участники, в этом контексте, называются сущностями. Примерами сущностей являются медиа-проигрыватели, устройства, служба подписки, упаковщики контента и т.п. С сущностями обычно связаны узлы. Сущность, которая потребляет контент, использует механизм ΌΚΜ и управляет, по меньшей мере, одним объектом «узел», который составляет ее индивидуальность. В одном варианте осуществления, предполагается, что сущность имеет доступ ко всем данным объектов «узел», которым она управляет, в том числе ко всей личной информации этих объектов.
4.1.2. Узлы.
Объекты «узел», которые участвуют в иллюстративном варианте осуществления системы вывода ключа, содержат ключи как часть своих данных. В одном варианте осуществления, узлы может содержать два общих типа ключей: ключи совместного пользования и ключ конфиденциальности. В нижеследующих разделах перечислены разные типы ключей, которые можно использовать в различных вариантах осуществления. Однако очевидно, что конкретная конфигурация может использовать только подмножество этих ключей. Например, система может быть настроена на работу только с парами ключей, без использования секретных симметричных ключей. В другом случае, система может быть сконфигурирована без предоставления узлам ключей конфиденциальности, если необходимо использовать только ключи совместного пользования.
4.1.2.1. Ключи совместного пользования.
Ключи совместного пользования представляют собой пару открытого/секретного ключей и/или симметричных ключей, которые совместно используются узлом N и всеми узлами Рх, для которых существует связь от Рх к Ν, которая содержит расширения вывода ключа.
Открытый ключ совместного пользования: КриЬ-8Йаге[К| Это открытая часть пары открытого/секретного ключей для шифра открытого ключа. Этот ключ обычно приходит с сертификатом, что позволяет проверять мандат сущностям, которые хотят криптографически связать с ним конфиденциальную информацию.
Секретный ключ совместного пользования: Крпу-8Наге| N | Это секретная часть пары открытого/секретного ключей. Сущность, управляющая узлом, призвана гарантировать, что этот секретный ключ держится в секрете. По этой причине, этот секретный ключ обычно хранится и переносится отдельно от остальной информации узла. Далее этот секретный ключ можно сделать совместно используемым с другими узлами посредством расширений вывода ключа в связях.
Симметричный ключ совместного пользования: 1<5-511аге|Щ Это ключ, который используется с симметричным шифром. Как и секретный ключ, этот ключ является конфиденциальным, и сущность, управляющая узлом, отвечает за сохранение его в секрете. Далее этот секретный ключ можно сделать совместно используемым с другими узлами посредством расширений вывода ключа в связях.
4.1.2.2. Ключи конфиденциальности.
Ключи конфиденциальности это пары ключей и/или симметричные ключи, известные только сущности, управляющей узлом, которой они принадлежат. Разница между этими ключами и вышеописанными ключами совместного пользования в том, что они не делаются совместно используемыми с другими узлами посредством расширений вывода ключа в связях.
Открытый ключ конфиденциальности. КриЬ-сопГ|Щ Это открытая часть пары открытого/секретного ключей для шифра открытого ключа. Этот ключ обычно приходит с сертификатом, что позволяет проверять мандат сущностям, которые хотят криптографически связать с ним конфиденциальную информацию.
Секретный ключ конфиденциальности. Κρήν<οηΓ[Ν] Это секретная часть пары открытого/секретного ключей. Сущность, управляющая узлом, призвана гарантировать, что этот секретный ключ держится в секрете. По этой причине, этот секретный ключ обычно хранится и переносится отдельно от
- 19 012918 остальной информации узла.
Симметричный ключ конфиденциальности: Ι<5-οοηΓ|Ν| Это ключ, который используется с симметричным шифром. Как и секретный ключ конфиденциальности, этот ключ хранится в секрете.
4.2. Криптографические элементы.
Предпочтительные варианты осуществления описанных здесь систем вывода и распространения ключа можно реализовать с использованием разнообразных криптографических алгоритмов, и они не ограничиваются каким-либо конкретным выбором криптографического алгоритма. Тем не менее, для данной(го) конфигурации или профиля, все участвующие сущности, в общем случае, должны согласовываться с набором поддерживаемых алгоритмов (термин «профиль», в целом, относится к спецификации набора фактических технологий, используемых в конкретной реализации (например, К8А для вывода ключа; ХМЬ для кодирования объектов; МР4 для формата файла и т.д.) и/или другому представлению семантического контекста, которое существует, когда объекты заданы в практической конфигурации).
В одном варианте осуществления, конфигурации включают в себя поддержку по меньшей мере одного шифра открытого ключа (например, К.8Л) и одного шифра симметричного ключа (например, АЕ8).
При описании криптографических функций будет использоваться следующая система обозначений:
Ερ(Κρι.ιό|Ν|. Μ) означает сообщение М, зашифрованное открытым ключом КриЬ узла N с использованием шифра открытого ключа;
Όρ(Κρήν[Ν], М) означает сообщение М, дешифрованное секретным ключом Κρτίν узла N с использованием шифра открытого ключа;
Ε8(Κ8[Ν], М) означает сообщение М, зашифрованное симметричным ключом К§ узла N с использованием шифра симметричного ключа;
Ό8(Κδ[Ν], М) означает сообщение М, дешифрованное симметричным ключом К§ узла N с использованием шифра симметричного ключа.
4.3. Нацеливание ключей контента.
В предпочтительном варианте осуществления используется два типа криптографического нацеливания. Нацеливание ключа контента на ключи совместного пользования конечного узла означает делание этого ключа доступным для всех сущностей, которые совместно используют секретные ключи совместного пользования этого конечного узла. Нацеливание ключа контента на ключи конфиденциальности уза означает делание этого ключа доступным только для сущности, которая управляет этим узлом. Нацеливание ключа контента осуществляется путем шифрования ключа контента СК, переносимого в объекте Соп1еп1Кеу, с использованием одного или обоих из следующих методов.
Открытое связывание: создание объекта СоШеШКеу, который содержит Ер(КриЬ[К|, СК).
Симметричное связывание: создание объекта СоШеШКеу, который содержит ЕДКДК], СК).
В предпочтительном варианте осуществления по возможности используется симметричное связывание, поскольку для него требуется менее вычислительно-интенсивный алгоритм, и поэтому оно менее обременительно для принимающей сущности. Однако сущность (обычно, упаковщик контента), которая создает объект Соп1еп1Кеу, не всегда имеет доступ к К§[К|. Если упаковщик не имеет К§[Щ, он может использовать открытое связывание, поскольку КриЬ[К| не является конфиденциальной информацией, и потому его можно сделать доступным для сущностей, которым нужно произвести открытое связывание. КриЬ[К| обычно делается доступным для сущностей, которым нужно нацеливать ключи контента совместно с сертификатом, который сущность может проверять для принятия решения, действительно ли КрцЬ[К| является ключом узла, которому можно доверить манипулировать ключом контента в соответствии с некоторой согласованной политикой (например, что узел соответствует сущности, выполняющей механизм ΌΚΜ и приложение хоста, которые согласуются с функциональными, операционными политиками и политиками безопасности системы).
4.4. Вывод ключей с использованием связей.
Чтобы сущность могла иметь доступ к ключам совместного пользования всех узлов, доступных из своего узла индивидуальности, в одном варианте осуществления, объекты «связь» содержат необязательную полезную нагрузку расширения ключа. Эта полезная нагрузка расширения ключа позволяет сущностям, которые имеют доступ к открытому/секретному ключам начального узла связи, также иметь доступ к личным/секретным ключам совместного пользования конечного узла связи. Таким образом, сущность может дешифровать любой ключ контента, нацеленный на узел, который доступен из ее узла индивидуальности (если нацеливание произведено с использованием ключей совместного пользования конечного узла).
В одном варианте осуществления, когда механизм ΌΚΜ обрабатывает объекты «связь», он обрабатывает полезную нагрузку расширения ключа каждой связи для обновления внутренней цепи ключей, к которой он имеет доступ. В одном варианте осуществления, полезная нагрузка расширения ключа связи Ь от узла Е к узлу Т содержит либо:
открытую информацию вывода: Ер(КриЬ-8Йаге[Е], {К8-8Йаге[Т],КргК-8Йаге[Т]}), либо симметричную информацию вывода: Е8(К8-8Йаге[Е], {К8-8Йаге[Т],Крггс-8Йаге[Т]}), где {К8-8Йаге[Т], КргК-8Йаге[Т]} - структура данных, содержащая К8-8Йаге[Т] и Кргтс-8Йаге[Т]. Открытая информация вывода используется для переноса секретных ключей совместного пользо
- 20 012918 вания узла Т, К8-8Йате[Т] и Крт1у-8Йаге[Т] на любую сущность, которая имеет доступ к личному ключу совместного пользования узла Е, Крпу-8Йате[Е].
Симметричная информация вывода используется для переноса секретных ключей совместного пользования узла Т, К8-8Йаге[Т] и Крг1у-8Йаге[Т], на любую сущность, которая имеет доступ к симметричному ключу совместного пользования узла Е, Кк-кйаге [Е].
Как и при нацеливании ключей контента на узлы, предпочтительная полезная нагрузка, подлежащая включению в связь, является симметричной информацией вывода. Это возможно, когда создатель связей имеет доступ к К8-8Йаге[Е]. Если нет, создатель связей делает шаг назад, включая в себя открытую информацию вывода в качестве полезной нагрузки для связи.
Предполагая, что механизм ΌΚΜ, обрабатывающий связь, уже имеет К8-8Йаге[Е] и Крг1у-8Йаге[Е] в своей внутренней цепи ключей после обработки связи, Ь[Е^Т], он также будет иметь К8-8Йаге[Т] и Крг1у-8Йаге[Т].
Поскольку, в одном варианте осуществления, связи можно обрабатывать в любом порядке, механизм ΌΡΜ может не иметь возможности производить вычисления для вывода ключа во время обработки данной связи Ь. Это может быть следствием того факта, что, в это время, цепь ключей механизма ΌΚΜ может еще не содержать ключи начального узла этой связи. В этом случае, связь запоминается и обрабатывается снова, когда новая информация становится доступной механизму ΌΚΜ, например, после обработки новой связи Р. Если конечный узел связи Р совпадает с начальным узлом связи Ь, и начальный узел связи Р является доступным узлом, то начальный узел связи Ь также будет доступным, и на этапе вывода ключа личные ключи совместного пользования начального узла связи Ь добавляются в цепь ключей.
5. Примеры реализации.
Ниже приведено несколько примеров, иллюстрирующих, как различные варианты осуществления описанных здесь систем и способов можно применять на практике. Описанные здесь системы и способы могут обеспечивать широкий круг функций управления правами и других функций, откуда следует, что приведенные здесь конкретные примеры не претендуют на то, чтобы быть исчерпывающими, но просто иллюстрируют объем изобретения.
5.1. Пример. Пользователи, ПК и устройства.
Предположим, что Вы хотите реализовать систему ΌΚΜ, которая связывает право на воспроизведение контента с конкретным пользователем, и Вы хотите облегчить для пользователя воспроизведение контента на всех устройствах воспроизведения, которыми он обладает. Предположим, что Вы решили снабдить пользователей программным обеспечением, которое позволяет им добавлять необходимые устройства воспроизведения (например, мобильные проигрыватели). Однако предположим также, что Вы хотите задать некоторую политику, ограничивающую количество устройств общего назначения, на которые пользователь сможет переносить контент, чтобы пользователь не имел возможности действовать как распространитель.
На основании этих системных требований, может иметь смысл, например, связывать создаваемые Вами лицензии с пользователями и устанавливать соотношения между пользователями и устройствами, которые они используют. Таким образом, в этом примере, Вы сначала можете решить, какого рода узлы Вам нужны для установления необходимых Вам видов соотношений. Например, Вы можете задать следующие типы узлов:
Пользователь (например, лицо, владеющее правами на использование контента);
ПК (например, прикладная программа, выполняющийся на персональном компьютере, которая может воспроизводить контент и указывать дополнительные устройства воспроизведения);
Устройство (например, портативное устройство для представления контента).
Каждый объект «узел» может включать в себя атрибут 1уре (тип), который указывает, представляет ли объект пользователя, ПК или устройство.
Пусть, например, Вы решили ограничить максимальное количество объектов «узел ПК», которые могут быть присоединены к любому пользователю в конкретный момент времени, четырьмя (4). Вы решили, что не нужно ограничивать количество устройств, присоединенных к пользователю, пока Вы обеспечиваете ограничение по количеству ПК. На основании этого, можно таким образом настроить программу управления, чтобы она разрешала доступ, если можно установить соотношение между узлом «пользователь» и узлом, запрашивающим доступ. Тогда этот узел может быть либо ПК, либо устройство.
На фиг. 16 показана система, призванная удовлетворять вышеизложенным требованиям. Сервер 1600 присваивает объект «узел «пользователь»» 1602а, 1602Ь каждому новому пользователю 1604а, 1604Ь, и регулирует способность пользователей 1604а, 1604Ь связывать с собой устройства 1606, 1608 и ПК 1610, 1612 с целью доступа к защищенному контенту. Когда пользователь 1604а желает связать новое устройство 1606 со своим узлом «пользователь» 1602а, сервер 1600 определяет, содержит ли уже устройство 1606 информацию персонализации 1614, что может иметь место, если устройство 1606 было персонализовано во время изготовления. Если устройство не содержит информацию персонализации 1614, сервер 1600 использует эту информацию персонализации 1614 для создания связи 1616 от устройства 1606 к узлу 1602а пользователя, и передает связь 1616 устройству 1606 пользователя. Когда пользо
- 21 012918 ватель 1604а получает защищенный контент 1618 (например, с сервера 1600 или от какого-либо другого поставщика контента), этот контент 1618 нацеливается на узел 1602а пользователя (например, путем шифрования ключа дешифрования контента одним из секретных ключей совместного пользования, связанных с узлом 1602а пользователя), и с ним связывается лицензия 1619, указывающая условия, при которых можно осуществлять доступ к контенту. Когда пользователь 1604а пытается воспроизвести контент 1618 на устройстве 1606, механизм ΌΚΜ 1620, выполняющийся на устройстве 1606, оценивает лицензию 1619, которая указывает, что контент 1618 можно воспроизводить, пока доступен узел «пользователь» 1602а. Механизм ΌΚΜ 1620 оценивает связь 1616, которая показывает, что узел «пользователь» 1602а доступен из устройства 1606, и удовлетворяет запрос пользователя 1604а на доступ к контенту
1618, например, авторизуя дешифрование ключа дешифрования контента, содержащегося в лицензии
1619.
Поскольку ключ дешифрования контента, в этом примере, зашифрован с использованием секретного ключа, связанного с узлом 1602а пользователя, этот секретный ключ нужно получить, чтобы дешифровать ключ дешифрования контента. Если используются описанные здесь в другом месте необязательные методы вывода ключа, ключ узла «пользователь» можно получить, просто расшифровав информацию вывода ключа, содержащуюся в связи 1616, с использованием одного из секретных ключей устройства 1606. Дешифрованная информация вывода ключа будет содержать ключ, необходимый для дешифрования ключа дешифрования контента, содержащегося в лицензии 1619 (или информации, из которой его можно вывести или получить).
Согласно, опять же, фиг. 16, предположим, что пользователь 1604а желает связать новый ПК 1610 со своим узлом «пользователь» 1602а. Сервер 1600 проверяет, не связано ли уже с узлом «пользователь» 1602а максимальное количество ПК, и авторизует связывание ПК 1610 с узлом «пользователь» 1602а. Однако для осуществления связывания сервер 1600 должен получить информацию персонализации от ПК 1610 (например, криптографические ключи, уникальный идентификатор и т.д.). Если же прежде не был персонализован РС 1610 (что может иметь место, если пользователь просто загрузил копию программного обеспечения ПК), сервер 1600 осуществляет процесс персонализации (например, создавая объект «узел РС» с использованием протокола загрузки, описанного здесь в другом месте) или направляет пользователя к поставщику услуг, который может осуществить процесс персонализации. По завершении процесса персонализации, сервер 1600 может создать связь 1624 от ПК 1610 к узлу «пользователь» 1602а и передать связь на ПК 1610, который может продолжать пользоваться ею, пока она остается действительной.
Позже пользователь может запросить добавление дополнительных ПК, и сервер будет применять политику, которая ограничивает количество объектов «узел РС» на одного пользователя числом 4 (обычно он также предоставляет пользователям возможность, при необходимости, удалять РС из своего активного списка).
В порядке еще одного примера, предположим, что поставщик услуг решил, что пользователи должны иметь возможность воспроизводить любой контент, которым они обладают, на любом принадлежащем им устройстве. Поставщик услуг также может пожелать позволить программному обеспечению ПК пользователя создавать связи с каждым из его устройств, не требуя от пользователя связаться с сервером 1600. В этом варианте осуществления, когда пользователь желает воспроизвести контент на новом устройстве, программное обеспечение ПК пользователя будет обращаться к конфиденциальной информации персонализации нового устройства и использовать ее для создания новой связи для этого устройства (например, связи от нового устройства к узлу 1602а пользователя). Если устройство не персонализовано, то программное обеспечение ПК может обратиться к удаленной службе или предписать устройству обратиться к удаленной службе, для осуществления процесса персонализации. Затем программное обеспечение ПК передает связь на новое устройство, и при этом новое устройство получает возможность воспроизводить контент, пока она остается действительной, поскольку, в одном варианте осуществления, если объект «связь» существует, нет необходимости создавать другую, пока не истечет срок действия объекта «связь» или он станет недействительным по другой причине.
В вышеприведенных примерах, контент нацеливается на пользователя. Для этого, приложение упаковщика выбирает новый ΙΌ для контента или использует существующий, создает ключ шифрования и соответствующий объект Соп1сп1Ксу. а также объект «протектор» для связывания объекта «контент» и объекта СоШегИКеу. Затем упаковщик создает объект управления с программой управления (например, компилированной в байт-код, который может выполняться на виртуальной машине механизма ΌΚΜ), что позволяет выполнять действие воспроизведение, если и только если узел «пользователь» доступен от узла ПК или «устройство», который запрашивает действие. Обычно объекты «управление», «контроллер», «протектор» и СоШсгИКсук по мере возможности внедряются в упакованный контент, благодаря чему ПК и устройствам не приходится получать их отдельно.
В одном варианте осуществления, когда устройство или ПК хочет воспроизвести контент, оно выполняет процесс, например, описанный выше в связи с фиг. 9. Таким образом, механизм ΌΚΜ находит объект «протектор» для еоп1сп1 ΙΌ контента, затем объект Соп1сп1Ксу, указанный этим протектором, затем объект «контроллер», на который ссылается этот объект СойепЖеу, и, наконец, объект управления,
- 22 012918 указанный этим контроллером. Механизм ΌΚΜ выполняет программу управления объекта управления, которая проверяет, доступен ли узел «пользователь». Если узел «устройство» или ПК имеет необходимые объекты «связь» для проверки наличия пути между своим узлом и узлом «пользователь», то условие выполняется, и программа управления позволяет использовать ключ, представленный в объекте Соп1еп1Кеу. Затем механизм медиа-представления устройства или ПК может дешифровать и воспроизвести контент.
5.2. Пример. Временный вход.
На фиг. 17 показан другой пример возможного применения описанных здесь систем и способов ΌΚΜ. Этот пример аналогичен примеру, приведенному в предыдущем разделе, за исключением того, что здесь политика, которая регламентирует создание объектов «связь» между объектами «узел РС» и объектами «узел «пользователь»» допускает временный вход не более чем на 12 ч, при условии, что пользователь уже не имеет временный вход на другом ПК. Эта особенность позволяет пользователю 1700 перенести свой контент 1702 на ПК друга 1704, зайти на этом ПК 1704 на период времени и воспроизвести контент 1702 на ПК друга 1704.
Для этого создается объект «связь» 1710 с ограниченным периодом действия. В одном варианте осуществления это можно делать следующим образом.
Для простоты объяснения, предположим, что потребляющее программное обеспечение 1714 с разрешенным ΌΚΜ, необходимое для воспроизведения ΌΚΜ-защищенного контента 1702 уже присутствует на ПК друга 1704. Файл, содержащий контент 1702 и лицензию 1708, переносится на ПК друга 1704. Когда пользователь пытается воспроизвести контент 1702, программное обеспечение 1714 распознает отсутствие действительных объектов «связь», связывающих локальный узел ПК с узлом пользователя, который владеет контентом. Программное обеспечение 1714 предлагает пользователю представить мандат 1712 (это может обеспечиваться через имя пользователя/пароль, протокол аутентификации мобильного телефона, смарт-карту или любую систему аутентификации, разрешенную согласно политике системы) и связывается с вычислительной системой базы данных 1706. Вычислительная система базы данных 1706 проверяет атрибуты объекта «узел «пользователь»» и объекта «узел ПК», для которых запрошена связь, и проверяет, нет ли активного объекта «связь» для временного входа, который все еще действителен. При выполнении этих условий, служба базы данных 1706 создает объект «связь» 1710, связывающий объект «узел РС» друга и узел пользователя, с периодом действия, ограниченным запрошенной длительностью входа (например, менее 12 ч, для согласования с политикой в этом примере). Наличие объекта «связь» 1710 позволяет ПК друга 1704 воспроизводить контент 1702 пользователя, пока не истечет срок действия связи 1710.
5.3. Пример: управление контентом предприятия.
На фиг. 18 показана высокоуровневая архитектура иллюстративной системы 1800 для управления документацией предприятия (например, электронной почтой, документами текстового редактора, слайдами презентации, текстами мгновенного обмена сообщениями и/или т.п.). В примере, показанном на фиг. 18, приложение редактирования документов (например, текстовый редактор) 1802, почтовый клиент 1804 и сервер директорий (например, сервер активной директории) 1806 используют плагин 1808 управления цифровыми правами (ΌΚΜ), уровень согласования сетевых услуг 1810, службу регистрации 1812 и службу политик 1816 для упрощения обработки документов, сообщений электронной почты, и/или т.п. в соответствии с политиками. В предпочтительном варианте осуществления, плагин ΌΚΜ 1808, уровень согласования сетевых услуг 1810, служба политик 1816 и служба регистрации 1812 реализованы с использованием механизма ΌΚΜ и технологии согласования услуг, описанной здесь в другом месте и в заявке '551. Например, в одном варианте осуществления, плагин ΌΚΜ 1808 может содержать вышеописанный вариант осуществления механизма ΌΚΜ. Очевидно, что, хотя на фиг. 18 показан вариант осуществления, в котором существующие приложения, например, текстовый редактор 1802 и почтовый клиент 1804 объединены с механизмом ΌΚΜ посредством плагина, который приложения могут вызывать, в других вариантах осуществления механизм ΌΚΜ может составлять неотъемлемую часть одного или обоих приложений. Также очевидно, что иллюстративную систему, показанную на фиг. 18, можно реализовать в пределах одного предприятия или можно распространить на несколько предприятий.
В иллюстрации, показанной на фиг. 18, сервер директорий 1806 может, например, содержать профили пользователей и определения групп. Например, системный администратор компании может задать группу под названием Команда особых проектов путем идентификации членов Команды особых проектов компании.
В одном варианте осуществления сервер директорий 1806 может содержать Сервер активной директории, выполняющий веб-услуги, например, описанные в заявке '551 (и реализованные, например, посредством стандартных технологий на основе 118 на платформе \Утбо\\ъ®). которые выдают узлы, связи и лицензии членам группы Команда особых проектов на основании контента, к которому осуществляется доступ. Если состав членов группы меняется, выдаются новые жетоны. Для отмены прав, сервер директорий 1806 может запустить услугу метаданных безопасности, основанную на технологии, например, описанной в заявке '551 (иногда именуемой здесь технологией ΝΕΜΟ). В некоторых вариантах осуществления, может потребоваться, чтобы клиент имел значение времени на данное число или обозна
- 23 012918 чение времени (на основании того, насколько свежее значение задается по выбору компании (например, 1 неделя, 1 день, 1 ч, каждые 5 мин и т.д.)) для использования лицензий ΌΚΜ. Например, жетон, предоставляемый услугой метаданных безопасности, может включать в себя доверенное и аутентифицируемое значение времени. В некоторых вариантах осуществления, клиент может идентифицировать ГО узлов «пользователь», взаимодействуя с услугой метаданных безопасности. Метаданные безопасности можно оценивать непосредственно в контексте объектов управления лицензии для определения, все ли еще пользователь имеет данную принадлежность. Метаданные безопасности также могут возвращать агенты, которые могут определять, действительны ли соотношения, например, членство в Команде особых проектов. Таким образом, в некоторых вариантах осуществления можно усовершенствовать существующую инфраструктуру авторизации и аутентификации компании (например, Сервер активной директории компании), просто добавив несколько четко прописанных веб-услуг.
На фиг. 19 показан пример, как систему, например, показанную на фиг. 18, можно использовать для управления доступом к документу или другим его использованием. В этом примере, конкретный служащий (Джон) может часто работать над высокосекретными стратегическими проектами, и может иметь уже установленный плагин ΌΚΜ 1908 для своих приложений (например, программы текстового редактора 1902, программы электронной почты 1904, программы календаря, программы или пакета программ, которая(ый) объединяет такие программы, и/или т.п.). В какой-то момент при создании документа, Джон обращается к элементу полномочия выпадающего меню, которое было добавлено в инструментальную панель его приложения (действие 1913). Открывается диалоговое окно полномочий, которое связывается с Сервером активной директории 1906 его компании для доступа к директории лиц и групп, зарегистрированных в системе. Он выбирает Команда особых проектов из списка, и выбирает дать каждому члену команды разрешение просматривать, редактировать и печатать документ. С использованием технологии согласования услуг ΝΕΜΟ, описанной в заявке '551, плагин ΌΚΜ 1908 связывается с расширением службы политик 1916 с разрешенным ΝΕΜΟ до Активной директории 1906 и запрашивает копию политики для использования с целью защиты файлов Команды особых проектов (действие 1914). Когда Джон сохраняет документ, плагин ΌΚΜ автоматически шифрует файл 1912, и создает объект «лицензия», нацеленный и связанный с группой под названием Команда особых проектов 1910. Лицензия 1910 позволяет осуществлять доступ к файлу 1912 (например, просмотр, редактирование, печать и т.д.) со стороны любого устройства, которое может создать действительную цепь связей от своего узла «устройство» к узлу «группа» Команды особых проектов.
Джон может осуществлять доступ к документу 1912, поскольку его устройство имеет связь с узлом «пользователь» Джона, а также имеет связь от узла «пользователь» Джона к узлу «группа» Команды особых проектов. Аналогично, если он пересылает этот документ другим людям, они могут осуществлять доступ к нему только, если они также могут создать действительную цепь связей к узлу «группа» Команды особых проектов (например, потребовав, чтобы узел «Команда особых проектов» был доступен устройству).
Джон может сохранить файл (уже защищенный) на своем компьютере, и затем присоединить его к сообщению электронной почты (действие 1920). Например, он может открыть старое сообщение электронной почты своему начальнику (Джорджу), присоединить файл, как он обычно это делает, и отправить сообщение. Согласно фиг. 20, Джордж также имеет плагин ΌΚΜ 2000, установленный на его компьютере 2014. Когда он входит на свой компьютер 2014, плагин 2000 своевременно проверяет все группы, в которые он добавлен (действие 2006), и загружает новые, обновленные связи для всех тех, срок действия которых истек (действие 2012). Если он добавлен в Команду особых проектов после своего последнего входа, его плагин 2000 загружает объект «связь» 2008, который связывает его узел «пользователь» с узлом «группа» Команды особых проектов. Эта связь 2008 указывает, что узел «пользователь» Джорджа является членом узла «группа» Команды особых проектов. В этом примере, предположим, что объект «связь» 2008 имеет дату окончания срока действия, после которой он уже недействителен (например, 3 дня).
Согласно фиг. 21, когда Джордж пытается открыть документ (действия 2130, 2132), плагин ΌΚΜ 2108 проверяет внедренную (или присоединенную) лицензию, и узнает, что узел Команда особых проектов должен быть доступным. Его плагин 2108 строит (и удостоверяет) цепь связей 2120, 2122 от узла «устройство» его компьютера к узлу «пользователь» Джорджа; и от узла «пользователь» Джорджа к узлу «группа» Команды особых проектов (действие 2134). Поскольку устройство имеет действительную цепь связей 2120, 2122, его плагин 2108 разрешает доступ к файлу.
Как описано здесь в другом месте, в некоторых вариантах осуществления связи также могут нести защищенную цепь ключей. Таким образом, в некоторых вариантах осуществления, создавая цепь связей к узлу «Команда особых проектов», плагин может удостоверять не только разрешение на доступ к контенту, но также то, что он способен дешифровать цепь ключей, которая позволяет ему дешифровать контент.
Если, например, другой сотрудник (Кэрол) случайно получает электронное письмо Джона и пытается открыть документ, ее плагин ΌΚΜ извлекает лицензию, связанную с файлом, и оценивает условия лицензии. Ее ПК имеет связь к ее узлу «пользователь» Кэрол; но, поскольку она не является членом ко- 24 012918 манды, не существует связи от Кэрол к узлу «группа» Команды особых проектов. Поскольку Команда особых проектов недоступна, Кэрол не разрешено обращаться к файлу.
Если Кэрол со временем добавляется с группу Команда особых проектов, в следующий раз, когда ее плагин ΌΚΜ будет обновлять ее отношения принадлежности, он обнаружит эту новую группу и загрузит объект «связь», который связывает ее узел «пользователь» с узлом «Команда особых проектов». Теперь ее плагин имеет все необходимые связи для построения цепи от ее узла «устройство» к ее узлу «пользователь» и далее к узлу «Команда особых проектов». Теперь узел «Команда особых проектов» доступен, и она может открывать любые документы и почтовые отправления, адресованные Команде особых проектов, даже созданные до того, как она стала членом команды.
Предположим, что месяц спустя Джордж переводится на новую роль и удаляется из группы «Команда особых проектов» в Активной директории. В следующий раз, когда Джордж осуществляет вход, его плагин не принимает новый, обновленный объект «связь», связывающий узел «пользователь» Джорджа с Командой особых проектов. Когда, спустя несколько недель, он пытается открыть файл Джона, его плагин пытается построить цепь связей к Команде особых проектов. Его ПК все еще имеет связь к узлу «пользователь» Джорджа (ПУ Джорджа все еще принадлежит ему); но связь от Джорджа к Команде особых проектов уже недействительна. Поскольку Команда особых проектов недоступна, ему не разрешено обращаться к файлу.
Предположим, что компания имеет политику, которая требует регистрировать в журнале доступ ко всей конфиденциальной информации. В одном таком варианте осуществления, политика для Команды особых проектов требует, чтобы все лицензии, созданные для этой группы, также требовали сбора информации о пользовании и передачи ее, например, в центральное хранилище. Таким образом, в этом примере, при оценивании (например, выполнении) программы управления в лицензии, плагин выполняет требование регистрировать доступ в журнале и делает это. Например, важные действия можно регистрировать в локальной защищенной базе данных состояний, например, описанной здесь, и, после восстановления связности сети, соответствующий контент можно сообщать через вышеописанные услуги.
На фиг. 22 показана другая иллюстративная система 2200 для управления электронным контентом на предприятии. В примере, показанном на фиг. 22, сервер ΕΟΛΡ 2206 используется для управления профилями пользователей, определениями групп и назначениями ролей и содержит определение группы под названием Команда особых проектов и определение роли Поверенный.
Предположим, что Джон является поверенным и желает послать электронное письмо с вложением другим членам Команды особых проектов. Когда Джон устанавливает плагин ΌΚΜ 2208 для своих приложений, он также устанавливает элементы в инструментальную панель своего почтового клиента. В некоторый момент при составлении сообщения электронной почты, Джон обращается к элементу Установить полномочия выпадающего меню, добавленного в его инструментальную панель. Плагин ΌΚΜ 2208 связывается со службой политик 2216 и отображает список корпоративных политик обмена сообщениями, из которого можно выбирать. Джон выбирает 8рес1а1 Рго)сс1 ΌΚΜ Тетр1а!е, и плагин ΌΚΜ 2208 использует протокол ΝΕΜΟ для запроса и удостоверения аутентичности, целостности и конфиденциальности объекта «политика», который он принимает. Политика описывает, как следует создавать лицензии, которые используют этот шаблон, в том числе, как их следует нацеливать и связывать.
Когда Джон кликает по элементу Отправить, плагин ΌΚΜ 2208 шифрует сообщение и вложение и генерирует соответствующую(ие) лицензию(и). Лицензия требует, чтобы, для доступа к электронной почте или вложению, узел «группа» Команды особых проектов или узел «группа» Поверенные должен быть доступным.
Лицензии связываются с зашифрованной полезной нагрузкой сообщения и зашифрованным вложением. Затем сообщение передается в список получателей с использованием стандартных функций электронной почты. Поскольку правила лицензии и шифрование не зависят от адресации электронной почты, тот факт, что неправильный получатель электронной почты может быть ошибочно включен, не подвергает опасности содержимое электронного письма или вложения.
Поскольку такой непреднамеренный получатель не имеет действительного объекта «связь», связывающего его узел «пользователь» с Командой особых проектов, ему не разрешается обращаться к контенту, если и когда он пытается сделать это. Кроме того, поскольку его устройство не имеет необходимой цепи связей (и ключей, которые они содержат), его устройство даже не имеет возможности дешифровать контент.
Однако, если непреднамеренный получатель, в свою очередь, пересылает то же самое, неизмененное электронное письмо с использованием стандартных функций электронной почты члену Команды особых проектов, этот член будет иметь объект «связь», который связывает его узел «пользователь» с узлом «группа» Команды особых проектов, и будет способен обращаться к содержимому электронного письма.
Предположим, что другой поверенный (Билл) в компании также получил объект «связь», который связывает его с узлом «группа» Команды особых проектов. Билл также может просматривать файл. Если он пересылает сообщение помощнику юриста (Тренту), который не является поверенным и не связан с Командой особых проектов, Трент не будет иметь объекта «связь», который связывает его с узлом
- 25 012918 «группа» Команды особых проектов, и он не получит доступ к документу.
Если Трент впоследствии добавляется в группу «Команда особых проектов» в директории ЬЭЛР 2206, он получает необходимые объекты «связь» и возможность доступа к ранее переправленному сообщению электронной почты.
Если, как рассмотрено выше, компания имеет политику, указывающую, что требование отчетности должно быть включено во все лицензии, то, в одном варианте осуществления, всякий раз при выполнении программы управления в одной из этих лицензий (например, когда кто-то пытается обратиться к файлу), может инициироваться событие отчетности. Этап отчетности может дополнительно включать в себя указатель, предоставлен доступ или же отклонен - это вопрос выбора реализации. При использовании такого указателя, может поддерживаться журнал количества попыток доступа к конкретному документу и состояния или иной информации каждой из них (например, успех, неудача и т.д.).
В порядке еще одного примера, предположим, что один из членов (Стивен) Команды особых проектов переходит в другую компанию для работы над особым проектом. До его перехода в другую компанию, почтовый клиент Стивена загружает локальную копию всех писем в его ящике входящих сообщений. Защищенный отчет, присоединенный к одному из этих писем, также включает в себя внедренную (или присоединенную) лицензию. Этот объект «лицензия» включает в себя как правила доступа к контенту, так и зашифрованный ключ контента. Только отсутствующая связь, необходимая для доступа к контенту, является необходимым объектом «связь» для достижения узла «группа» Команды особых проектов.
Поскольку в этом примере политика компании разрешает объектам «связь» оставаться действительными в течение 3 дней, объект «связь», который связывает узел «пользователь» Стивена с узлом «Команда особых проектов», будет оставаться действительным, пока он переходит и отключается. Если он попытается обратиться к файлу в автономном режиме, узел «группа» Команды особых проектов все еще будет доступен, и ему будет разрешено обратиться к файлу.
Если же 81ср11сп останется в автономном режиме в течение более трех дней, объект «связь», связывающий его с Командой особых проектов, утратит силу. Узел «группа» Команды особых проектов станет недоступным, и Стивену не будет разрешено обращаться к файлу.
Если Стивен, в конце концов, окажется в месте, где он сможет связаться с системой компании (например, через νΡΝ), его плагин ΌΚΜ запросит обновленные копии объектов «связь» для каждой из групп, которым он принадлежит. Поскольку он все еще является членом группы Команда особых проектов, он получит новый объект «связь» от своего узла «пользователь» к узлу «группа» Команды особых проектов. Эта связь заменит 'старую' связь, которая утратила силу и более недействительна.
Поскольку узел Команда особых проектов теперь доступен с использованием этой новой, обновленной связи, Стивен опять получает возможность обращаться к защищенному отчету. Новый объект «связь» будет действителен в течение 3 дней, после чего также утратит силу.
В порядке еще одного примера, предположим, что член Команды особых проектов (Салли) желает связаться с другим членом команды посредством службы мгновенного обмена сообщениями, сохранить копию сообщений и передать ее еще одному члену команды (например, в виде вложения электронной почты, дискеты, защитной заглушки и т. п.). В этом примере, клиент службы мгновенного обмена сообщениями (и, возможно, любых других продуктов для обмена сообщениями или связи, которыми компания снабжает своих сотрудников) привязывается к плагину ΌΚΜ, ^Ысй, как и в предыдущих примерах, обращается к политике 8рсс1а1 Рго)сс1 ΌΚΜ Тстр1а1с, которая определяет, как нужно нацеливать и привязывать лицензии. Когда Салли пытается сохранить свои переговоры в службе мгновенного обмена сообщениями (например, выбирая Сохранить как...), плагин выбирает ключ шифрования (например, произвольно) и упаковывает (шифрует) текст переговоров. Согласно политике компании, плагин ΌΚΜ генерирует объект «лицензия», который нацеливается и привязывается к узлу «группа» Команды особых проектов.
Файл, содержащий защищенный дубликат ΙΜ, связывается с лицензией на доступ к содержимому дубликата. Как и в предыдущих примерах, лицензия содержит как правила, которые регламентируют доступ к контенту, так и зашифрованную копию ключа контента.
Салли может перенести этот связанный файл в сообщение электронной почты, на защитную заглушку И8В, дискету и т.д. с использованием стандартных процедур 'перетаскивания', и отправить его кому-то еще. При условии, что устройство получателя может создавать действительные связи к узлу «группа» особых проектов, доступ к контенту разрешен и возможен.
Предположим, что Салли передает файл Джону, который также является членом Команды особых проектов. Если Джон имеет недавно обновленный объект «связь», который идентифицирует его как члена Команды особых проектов, он сможет обращаться к файлу. Согласно политике компании этот объект «связь» содержит дату окончания срока действия, согласно которой срок его действия истекает через три дня. Поэтому, даже если Джон остается отключенным, он все же будет иметь доступ, пока эта связь остается действительной.
Если некоторое время спустя Джон уходит из Команды особых проектов на другую работу и находит в своей сумке защитную заглушку И8В от Салли и пытается открыть файл с использованием своего
- 26 012918 настольного компьютера, объект «связь», связывающий его узел «пользователь» с Командой особых проектов утратит силу. Поскольку он больше не является членом команды, плагин ΌΚΜ на его устройстве уже не может найти новые, обновленные связи. Поскольку узел «группа» Команды особых проектов уже недостижима с его устройства, доступ не разрешается.
Полагая, что его портативный компьютер не подключался к сети с тех пор, как он сменил работу, он также пытается открыть файл с этого устройства. Поскольку максимальное предоставленное время прошло, эта связь больше не действительна. В некоторых вариантах осуществления, каждый раз, когда он пытается обратиться к файлу, может генерироваться отчет, который ставится в очередь на отправку в центральное хранилище.
Центральное хранилище принимает многочисленные отчеты о безуспешных попытках доступа к файлу и сигнализирует менеджеру по электронной почте. Менеджер напоминает Джону, что ему больше не разрешено обращаться к конфиденциальному материалу, и просит уничтожить все файлы (несмотря на то, что система указывает, что доступ не может быть предоставлен).
В порядке еще одного примера, предположим, что государственное агентство или внешний аудитор желает провести расследование или инспекцию, как Команда особых проектов обращается с конфиденциальной информацией. Чтобы помочь расследованию, компания желает продемонстрировать контрольные записи, касающиеся доступа важной информации в связи с Особым проектом.
С этой целью компания сначала сканирует все архивы незашифрованных сообщений на предмет любых сообщений, связанных с Особым проектом. К их облегчению, они обнаруживают, что, в соответствии с политикой компании, никто из сотрудников не посылал сообщений, касающихся Особого проекта, без надлежащей ΌΚΜ-защиты (например, за пределы системы).
Затем компания использует записи доступа ΌΚΜ для создания контрольного журнала, где подробно указано, кто и когда имел доступ к защищенной информации.
Согласно процедуре, принятой в компании, при создании группы «Команда особых проектов», в нее по умолчанию вводится начальник правового отдела (ССО). Объект «связь» для начальника правового отдела создается и сохраняется на архивном сервере, что позволяет ему, при необходимости, просматривать содержимое всех сообщений в будущем.
В этом примере политика, определенная для Команды особых проектов, указывающая, что все лицензии, создаваемые командой, должны включать в себя обязательный отчет обо всех попытках доступа к файлу, включающий в себя дату и время, икегЫобе, и был ли предоставлен доступ. Эти отчеты сохраняются в журнале доступа в центральном хранилище.
ССО проверяет журналы доступа для всех случаев доступа, связанных с Командой особых проектов, до того дня, когда возникло подозрение в утечке информации или нарушении правил. ССО также производит поиск в архивах электронной почты, ΙΜ и сетевого резервирования на предмет всех переданных сообщений и системных файлов на этот день и до него. Поскольку к каждому файлу присоединена лицензия (с ключом контента), и ССО имеет необходимые объекты «связь», удовлетворяющие требованиям лицензии, ему разрешен доступ к содержимому всех сообщений, к которым был совершен доступ до указанного времени.
Журналы доступа и содержимое незашифрованных сообщений поступают в полное распоряжение агентства/аудитора в порядке расследования.
В некоторых вариантах осуществления политика для Команды особых проектов также может включать в себя необходимость задавать дату окончания срока действия всех лицензий, относящихся к Особому проекту. Например, если компания лишь по закону обязана хранить записи такого рода в течение 1 года, она может указать в политике, что лицензии утрачивают силу через год после даты выпуска. В этом случае, компания может хранить записи ровно столько времени, сколько предписывает закон. После этого даже ССО не имеет к ним доступ.
В рассмотренном выше материале иногда упоминалось нацеливание и привязка. В предпочтительных вариантах осуществления, нацеливание и привязка представляют два разных, но тесно связанных между собою процесса. В предпочтительных вариантах осуществления, привязка это, в основном, криптографический процесс, относящийся к защите ключа, который используется для шифрования контента. Когда лицензия 'привязана' к узлу (например, узлу Команда особых проектов), это может означать, например, что ключ контента зашифрован открытым ключом, связанным с этим узлом. Таким образом, только устройства, имеющие доступ к секретному ключу узла, будут иметь необходимый ключ для дешифрования контента (и, в предпочтительных вариантах осуществления, единственным путем к получению доступа к секретному ключу узла является дешифровка цепи связей к этому узлу); однако, просто наличие правильного секретного ключа указывает только, что устройство имеет возможность дешифровать контент, но ему еще нужно получить на это разрешение.
В предпочтительных вариантах осуществления, разрешено ли устройству обращаться к контенту, определяет программу управления в лицензии, и, в частности, как она нацелена.
Нацеливание означает добавление требования в программу управления для указания, что конкретный узел (или узлы) доступны для осуществления пользования контентом. В вышеприведенных примерах, программа управления обычно указывает, что конкретный узел Команда особых проектов
- 27 012918 доступен потребляющему устройству.
В ряде случаев может быть желательно, чтобы лицензии были нацелены на более чем один узел, например, команда по разработке нового продукта в компании (Компания), которая работает со многими поставщиками, поставляющими компоненты для нового совершенно секретного продукта. Предположим, что на ранних стадиях проекта, поставщик А и поставщик В (конкуренты) имеют связи к 8есге1Рго)ес1Х. Поставщик А желает поделиться своими идеями со всеми членами 8есте1Рго_)ес1Х, но не хочет, чтобы, по неосторожности, они стали известны поставщику В. Поставщик А может нацеливать свои лицензии так, что: (8есге1Рго_)ес1Х доступен) и (Поставщик А доступен или Компания доступна). Если Компания непреднамеренно предает эту информацию гласности во всём 8есге1 Рго)ес1 X (в том числе, и для поставщика В), поставщик В не получит разрешения взглянуть на нее, что ограничивает всякую опасность неразглашения для Компании и ограничивает возможность поставщика А потерять свои коммерческие секреты.
5.4. Пример. Записи системы здравоохранения.
На фиг. 23 показано применение описанных здесь систем и способов для управления записями системы здравоохранения. Предположим, что медицинские записи имеют разные уровни конфиденциальности, и что желательно предоставлять разные права доступа разным сущностям в системе (например, пациентам, врачам, страховым компаниям и т.п.). Например, может быть желательно разрешать просматривать некоторые записи только пациенту, разрешать просматривать некоторые записи только врачу пациента, разрешать просматривать некоторые записи пациенту, но только в редакции врача пациента, разрешать просматривать некоторые записи всем врачам, разрешать просматривать некоторые записи всем страховым компаниям, разрешать просматривать некоторые записи только страховой компании пациента, и/или т. п.
Согласно фиг. 23, эту экосистему здравоохранения 2300 можно смоделировать с использованием объектов ΌΚΜ наподобие узлов и связей, например, описанных здесь в другом месте. Например, узлы можно присваивать пациенту 2302, врачам 2304 пациента, страховой компании 2306 пациента, устройствам (2308, 2310) пациента, конкретному одному из врачей 2312 пациента, вычислительным устройствам 2314, 2316 врача, группе всех врачей 2318, группе врачей определенной специализации 2320, медицинскому учреждению 2322, страховой компании 2324, вычислительным устройствам, используемым страховой компанией 2326, группе всех страховых компаний 2328, и т.п.
Предположим, что врач пациента использует свой ПК для создания медицинской записи, касающейся пациента. Например, медицинская запись может содержать шаблон документа содержащий поля для примечаний, диагнозов, рецептов, инструкций для пациента и/или т.п. Шаблон также может позволять врачу выбирать политики безопасности для управления документом и/или отдельным его полем. Например, приложение врача может предоставлять возможность выбора из набора стандартных политик безопасности, и, получив выбор врача, может автоматически генерировать лицензию на основании этих выборов и связывать защищенный (например, зашифрованный) контент медицинской записи.
В целях этого примера, предположим, что лицензия предоставляет доступ для просмотра пациенту, всем поставщикам услуг здравоохранения, которые лечат пациента, и всем страховым компаниям, которые обеспечивают покрытие для пациента. Кроме того, предположим, в целях иллюстрации, что лицензия предоставляет права редактирования только кардиологу в медицинском учреждении х.
Приложение упаковки принимает ввод, указывающий политику врача (который может просто содержать кликанье мышкой по стандартному шаблону) и генерирует лицензию, которая включает в себя программу управления, например, приведенную ниже:
Αοΐιοη.Εάιί,Рег£огга() { ι£ (1еИо0еВеасЬаЫе (Μβάιθ31ΕΌυηά3ϋιοηΧ'') && 1вИос1еКеасЬаЫе (Сагйю1од151:) ) { геСигп пен Е8В(ΑΟΤΙΟΝ_ΰΒΑΝΤΕΟ);
) е1ее { ге£игп пей ЕЗВ(ΑΟΤΙΟΝ_ΟΕΝΙΕΟ);
} }
АсМоп. νίθΗ. Рег£огт() { ίί (1зЫос1еВеаскаЬ1е (Ра£1еп£У) II 1зЫос1еКеасЬаЫе (НСРэРа£1еп£У) I I 1зИодеВеасИаШе (1СзРаЫепСУ) ( геЁигп пен ЕЗВ(АСТ1ОЫ_СКАЙТЕО);
} е1зе ίί (ЕгпегдепсуЕхсерМоп == ТЕШЕ) ( геЁигп пен ЕЗВ(ΑΕΤΙΟΝΟΒΑΝΤΕΌ, пен Мо£1£1са£1оп0Ы1да£ίοη());
) е1зе ( ге£игп пен ЕЗВ (АСТ1ОМ_ЕЕ1ПЕВ) ;
} )
- 28 012918
Медицинскую запись и связанную с ней лицензию можно затем сохранить в центральной базе данных медицинских записей, базе данных, которой управляет конкретное медицинское учреждение, и/или т.п. Если пациент Υ впоследствии посещает другого поставщика услуг здравоохранения и авторизует этого поставщика услуг здравоохранения как одного из его доверенных поставщиков услуг здравоохранения (например, подписывая форму авторизации), этот поставщик услуг здравоохранения получает связь к арргоуеб узлу «доверенный поставщик услуг здравоохранения» пациента у, которую поставщик услуг здравоохранения будет хранить на своей компьютерной системе. Если этому поставщику услуг здравоохранения понадобится обратиться к медицинской записи, созданной врачом х, он сможет получить доступ для просмотра этой медицинской записи, поскольку узел «доверенный поставщик услуг здравоохранения» пациента у будет доступен от компьютерной системы нового поставщика услуг здравоохранения. Если же, недоверенный поставщик услуг здравоохранения захочет получить копию (зашифрованной) медицинской записи, он не сможет обратиться к ней ввиду отсутствия необходимых узлов (т.е. узла пациента у, узла для всех доверенных поставщиков услуг здравоохранения пациента у и узла для всех доверенных страховых компаний пациента у), которые были бы доступны от его вычислительной системы.
Заметим, однако, что показанная выше иллюстративная программа управления включает в себя доминирующую особенность, которую можно вызывать, например, в экстренных случаях, если, например, поставщик услуг здравоохранения нуждается в доступе к защищенной медицинской записи, но не может выполнить условия программы управления (например, потому, что поставщик услуг здравоохранения, пытающийся сделать экстренный доступ к медицинской записи, ранее не был зарегистрирован как поставщик услуг здравоохранения пациента Υ). Однако заметим также, что вызов исключения экстренного доступа приводит к автоматической записи информации, касающейся вызова и/или иных обстоятельств, и, в этом примере, также приводит к отправке извещения (например, предпочтительному поставщику услуг здравоохранения пациента, т.е. сущности, в явном виде авторизованной пациентом, и/или самому пациенту). Связывание таких обязательств с экстренным исключением может препятствовать злоупотреблению исключением, поскольку будет существовать запись о злоупотреблении.
Очевидно, что эта иллюстративная программа представлена для облегчения объяснения определенных вариантов осуществления описанных здесь систем и способов. Например, включает ли в себя система поддержку экстренных исключений, обычно зависит от требований и желаний архитектора системы. Таким образом, например, некоторые варианты осуществления могут не поддерживать экстренные исключения, другие могут поддерживать экстренные исключения, но ограничивать класс сущностей, которые могут вызывать такие исключения, классом все врачи (например, за счет требования, чтобы флаг ЕтегдеисуЕхсерйои был задан равным истина И узел «все врачи» был доступен), и другие все же могут поддерживать экстренные исключения, но не связывать с ними принудительные обязательства (поскольку неспособность выполнить обязательство, в предпочтительном варианте осуществления, сделает контент недоступным), опираясь вместо этого на нетехнические, правовые или институциональные средства применения (например, путем оказания доверия поставщикам услуг здравоохранения, не злоупотребляющим возможностью вызывать исключение, и/или опираясь на промышленную сертификацию и правовую систему для предотвращения злоупотреблений).
Еще одно изменение, которое можно внести в вышеприведенные примеры, состоит в том, что можно потребовать более сильное доказательство того, что к медицинской записи обратился действительно врач, или врач с конкретным именем, а не кто-то другой, сидящий за компьютером, который врач использует для доступа к записям (и, таким образом, компьютером, потенциально содержащим связи, необходимые для удовлетворения анализа доступности). Такую усиленную форму аутентификации можно осуществлять любым подходящим способом. Например, ее можно полностью или частично осуществлять на уровне приложения или системы, защищая компьютер врача и/или программное обеспечение, используемое для доступа к медицинским записям, с использованием паролей, защитных заглушек, механизмов биометрической идентификации и/или т. п. Альтернативно или дополнительно, программы управления, связанные с определенными медицинскими записями сами могут включать в себя обязательство или условие, требующее такой усиленной идентификации, например, проверку наличия защитной заглушки, требование, чтобы хост получил пароль, и/или т. п.
5.5. Пример. Подписки.
На фиг. 24 показано, как представленные здесь системы и способы можно использовать в контексте службы электронной подписки. Пусть, например, пользователь (Алиса) желает получить подписку на джазовую музыку от поставщика услуг интернета (ΧΥΖ 18Р). Поставщик услуг интернета может предлагать разнообразные варианты подписки, включающие в себя пробную подписку, не требующую оплаты, но которую можно использовать только для воспроизведения контента подписки пять раз до истечения срока (например, проиграть одну песню пять раз, проиграть пять разных песен по одному разу, и т.п.). Пробная подписка также может предусматривать обеспечение контента в слегка ухудшенной форме (например, с пониженным качеством звучания или разрешением). Алиса использует свой персональный компьютер для доступа к интернет-сайту поставщика услуг и выбирает пробную подписку. Тогда поставщик услуг создает объект «связь» 2400 и агент 2401 и передает их на персональный компьютер 2406
- 29 012918
Алисы. Агент 2401 способен инициализировать состояние защищенной базы данных состояний Алисы, которая будет использоваться для отслеживания, сколько раз Алиса использовала пробный контент. Связь 2400 идет от узла учетной записи Ι8Ρ Алисы (ΛΓ1ηοα@.ΧΥΖ_Ι8Ρ) 2402 к узлу подписки 2404 и включает в себя программу управления, которая, когда Алиса запрашивает воспроизведение фрагмента контента, проверяет текущее значение переменной состояния, заданной агентом 2401, чтобы определить, разрешены ли дополнительные воспроизведения.
Когда Алиса загружает фрагмент контента на свой ПК и пытается воспроизвести его, механизм ΌΚΜ на ее ПК оценивает лицензию, связанную с контентом, которая указывает, что узел подписки 2404 должен быть доступным для воспроизведения контента. Алиса ранее зарегистрировала свой ПК у своего Ι8Ρ, и при этом получила связь 2405 от своего узла ПК 2406 к своему узлу учетной записи 2402. Таким образом, механизм ΌΚΜ обладает объектами «связь» 2405, 2400, соединяющими узел ПК 2406 с узлом подписки 2404; однако, прежде чем удовлетворить запрос Алисы на воспроизведение контента, механизм ΌΚΜ сначала определяет, действительны ли связи, выполняя любые программы управления, содержащиеся в связях. При выполнении программы управления в связи 2400, механизм ΌΚΜ проверяет элемент базы данных состояний для определения, осуществлено ли воспроизведение 5 раз, и, если нет, удовлетворяет запрос на воспроизведение контента, но также выдает обязательство на приложение хоста. Обязательство требует, чтобы хост ухудшил контент до представления. Приложение хоста определяет, что оно способно выполнить это обязательство, и переходит к представлению контента. Для обеспечения Алисы предварительным просмотром контента до учета этого контента в отношении ее пятикратного пробного воспроизведения, программа управления должна также включать в себя обратный вызов, который проверяет, например, через 20 с после удовлетворения запроса на воспроизведение фрагмент контента, продолжается ли воспроизведение контента. Если контент все еще воспроизводится, счетчик воспроизведения уменьшается, а в противном случае - нет. Таким образом, Алиса может выбирать любые из элементов контента, предлагаемых службой подписки, и воспроизводить любые пять из них до истечения срока пробной подписки.
По истечении срока пробной подписки Алисы, она решает приобрести полную, месячную подписку, которая позволяет ей воспроизводить столько элементов контента, сколько она желает, за месячную плату. Алиса использует свой ПК для заказа подписки и получает связь 2410 от своего узла учетной записи 2402 к узлу подписки 2404. Связь включает в себя программу управления, указывающую, что связь действительна только в течение одного месяца (например, программа управления проверяет элемент базы данных состояний, чтобы определить, истек ли месяц с момента выдачи связи). Эта связь 2410 передается на ПК Алисы совместно с программой-агентом, которая способна инициализировать соответствующий элемент базы данных состояний механизма ΌΚΜ ПК, указывающий дату выдачи связи. Когда Алиса загружает фрагмент контента из службы подписки и пытается воспроизвести его, ее механизм ΌΚΜ ПК определяет, что существует путь к узлу подписки, состоящий из связей 2405, 2410. Механизм ΌΚΜ выполняет любые программы управления, содержащиеся в связях 2405, 2410 для определения, действительны ли связи. Если с момента выдачи связи 2410 прошло меньше месяца, программа управления в связи 2410 возвращает результат, указывающий, что связь 2410 все еще действительна, и запрос Алисы на воспроизведение фрагмента контента удовлетворяется. Если Алиса пытается воспроизвести фрагмент контента, который она ранее получила в течение своего пробного периода, механизм ΌΚΜ на ее ПК осуществляет такой же анализ и удовлетворяет ее запрос. Поскольку лицензия, связанная с фрагментом контента, полученная в течение пробного периода, указывает, что если переменна Тпа181а1с в защищенной базе данных не задана, то единственное условие состоит в том, что узел подписки должен быть доступным, Алиса может снова обратиться к этому контенту, поскольку узел подписки снова доступен от ПК Алисы, на этот раз через связь 2410, а не связь 2400, которая уже недействительна. Таким образом, Алисе не нужно получать вторую копию элемента контента для замены копии, которую она получила в течение бесплатного пробного предложения. Аналогично, если Алиса получает фрагмент контента подписки от своего друга Боба, который также подписался на ту же услугу, Алиса, в этом примере, тоже сможет воспроизводить этот контент, поскольку лицензия контента просто требует, чтобы узел подписки был доступен, не обязательно через ПК или учетную запись Боба.
Очевидно, что вышеприведенные примеры призваны просто иллюстрировать некоторые функции, которые могут быть обеспечены описанными здесь системами и способами, и не призваны указывать, что подписки должны быть реализованы именно вышеописанным образом. Например, в других вариантах осуществления, лицензия, связанная с фрагментом контента подписки можно связывать с узлом пользователя, а не с узлом подписки, что препятствует двум подписчикам, например, Бобу и Алисе, совместно использовать контент, что возможно в вышеописанном примере. Очевидно, что возможны многие другие вариации вышеприведенных примеров.
В нижеприведенной таблице представлен некоторый иллюстративный псевдокод для агента, связи и программ управления лицензии в вышеописанном примере:
- 30 012918
Пробная подписка обеспечивает доступ к контенту подписки в объеме до 5 фрагментов. Контент помечается как представляемый только спустя 20 секунд представления. Контент, представляемый в пробном режиме, будет ухудшен приложением представления.
Реальная подписка будет обновляться каждый месяц и не имеет подобных ограничений по количеству и качеству представлений.
Ниже представлен код агента:
Тг1а1Адеп1: () {
ЗекОЬ^еск (ТгЭаЗ-Зкаке'1, 5) }
Код программы управления в пробной связи
СопСго1. Ыпк. Соиз£га1ПС. Сйеск. {) { ΐί (СеиОЬзеск (Тг1а1зга1:е”, 5) > 0) { гекигп ЗСССЕЗЗ;
} е1зе ( ге£игп ΕΑΙΙΑ7ΚΕ;
)
Когда Алиса действительно регистрируется в службе подписки, она получает связь (начало: Алиса, коней: Подписка) и агент
Ниже представлен код агента:
Неа15иЬзсг1рЕ1опАдеп£() { // очистить Тг1а18£а£е, если присутствует Ъг1а15ЪаЬе = СеЪОЬзес!: ('’Тгга13£а£е);
1£ иг1а151:а1:е != ыиьь} ( Зе^ОЬ^есЪ(иТг1а13£а£е, ЫиЬЬ); // очистить }
}
Ниже представлен код связи
Ссп£го1 .Ыпк.СопзСгагпВ.СЬеск () (
1£ (СеЪТгцзЬесГПте () < Ехрз.га£лоп0а£е) ( ге£игп зисСЕЗЗ;
) е1зе { геГигп ГАХЪиКЕ;
) }
Все лицензии контента, нацеленные на подписку, имеют одну и ту же программу управления:
АсВХоп. Р1ау. Рег£огггЦ ) { // сначала проверить, доступен ли узел подписки ϊ£ (I ТаКоЗеКеасЬаЫе (ЗиЬзсгхрЧопИойе ) ) { гекигп пен Е5В(ΑΟΓΙΟΝ_ΟΕΝΙΕΟ};
} // теперь проверить, присутствует ли Тг1а15Ъа£е
1£ (5е£ОЬэес1: (’’Тг1а13£а£:®) 1- ыищ) ί // мы в пробном режиме: нам нужны обратный вызов и обязательство гекцгп пен Ξ5Β(АСТ1ОМ_СКАЫТЕО, пем 0пТ1теЕ1арзедСа11Ьаск(20, ОесгетепССоип^ег), пем Оедга<1еВеп^ег1пдОЫ1да1:1оп {) ) ;
) е1зе { // мы в режиме платной подлиски: просто возвратить АСТЮЬМЗВАКТЕб гекигп пей ЕЗВ (АСТЮМ^СКАИТЕО) ;
} }
// код функции обратного вызова 0пТйпеЕ1арзес£ ОесгетепкСоипЪег{} {
ЗеГ0Ъ}есЪ(Тг1а13£а£е, СеВОЬзес£(Тг1а13£аЪе”) - 1);
}
Опять же, согласно фиг. 24, Алиса также имеет учетную запись 2420 у своего поставщика услуг мо
- 31 012918 бильной связи, которая остается действительной, пока она остается подключенной к сети.
Алисе не требуется производить специальный платеж за подписку, взамен чего она получает связь; вместо этого обновление связей 2424 автоматически поступает на ее телефон, когда она подключается к сети. Эти связи позволяют ей осуществлять доступ к любым элементам контента или услугам, предлагаемым поставщиком услуг мобильной связи, которые имеют лицензии, которые требуют только, чтобы узел подписки 2422 был доступен. Если Алиса сменит поставщика услуг мобильной связи, она не сможет осуществлять доступ к ранее полученному контенту по истечении срока действия ее связей 2424.
На фиг. 25 показан пример того, как поставщик услуг может взаимодействовать с доменом домашней сети 2500. В этом примере, устройства зарегистрированы в домене домашней сети, где применяется политика, которая позволяет до 5 устройств принадлежать домену в любой момент времени. Хотя поставщик услуг кабельного телевидения семьи Смитов не обеспечивает программное обеспечение менеджера доменов, используемое для установления домена домашней сети 2500, поставщик услуг кабельного телевидения знает, что менеджер доменов реализован сертифицированным поставщиком программного обеспечения менеджера домена домашней сети, и, таким образом, доверяет программному обеспечению менеджера доменов действовать, как положено. Согласно фиг. 25, семья Смитов подключает телефон и ПК Алисы, РУК Карла и Р8Р Джо к домену 2500, в результате чего создаются связи от каждого из этих устройств к узлу домена 2500. В случае приема нового контента, например, на РУК, услуги обнаружения, например, описанные в заявке '551, позволяют другим устройствам в домене автоматически получать контент и любые необходимые необходимый связи. Создаются связи от узла «домен» 2500 к узлу «учетная запись» 2502 поставщика услуг. Контент некоторых поставщиков услуг кабельного телевидения имеет лицензию с обязательством, что перемотка вперед и назад должна быть отключена, чтобы можно было показывать рекламу. РУК Карла и ПК Алисы способны выполнять обязательство и, таким образом, могут воспроизводить контент. Мобильный телефон Алисы не может выполнять обязательство и поэтому не получает доступ к контенту.
5.6. Дополнительные примеры: совместное использование контента и прав.
Как показано в предыдущих примерах, представленные здесь варианты осуществления систем и способов позволяют естественным образом делать электронный контент совместно используемым. Например, описанные здесь системы и способы можно использовать для того, чтобы потребители могли совместно использовать развлекательный контент со своими друзьями и членами семьи, и/или наслаждаться им на всех своих семейных устройствах, и, в то же время, препятствовать более широкому, неавторизованному распространению. Например, можно использовать автоматизированные услуги обнаружения и оповещения равноправных устройств, в результате чего, когда одно устройство получает контент или соответствующие права, другие устройства могут автоматически узнавать об этом контенте, тем самым обеспечивая виртуальную распределенную библиотеку, которая может автоматически обновляться. Например, в одном варианте осуществления, если один пользователь получает контент или права на портативном устройстве в одном месте, а затем приходит домой, семейные устройства пользователя могут автоматически обнаруживать и использовать эти права. Напротив, если пользователь получает права на устройстве в своей домашней сети, его портативные устройства могут обнаруживать и переносить этот контент для использования в другом месте. Предпочтительные варианты осуществления описанных здесь систем и способов можно использовать для создания объектов услуг и прав, которые позволяют полностью автоматизировать вышеописанные сценарии с использованием, например, методов обнаружения и инспекции услуг, описанных в заявке '551. Например, устройства, зарегистрированные в конкретном домене, могут предоставлять услуги друг другу (например, путем совместного использования прав и контента), и/или можно вызывать удаленные службы для облегчения локального совместного пользования контентом. Описанные системы и способы позволяют создавать структуры ΌΚΜ, которые не нацелены на предотвращение создания копий само по себе, но призваны работать в гармонии с сетевой технологии, позволяя совместно использовать контент, в то же время, не позволяя потребителям становиться незаконными распространителями контента.
Предпочтительные варианты осуществления описанных здесь систем и способов ΌΚΜ также позволяют определять права без обширной характеристики типов выражений прав некоторых других систем ΌΚΜ. Вместо этого, предпочтительные варианты осуществления используют набор специализированных объектов прав, которые могут взаимодействовать контекстуально. Эти объекты описывают соотношения и управляющие элементы между сущностями, например пользователями, устройствами, контентом и их группами. Например, такие контекстуальные взаимодействия могут позволять устройству определять, что данный фрагмент контента можно воспроизводить, поскольку (а) контент получен от законной услуги контента, на которую пользователь в настоящее время подписан, (Ь) пользователь входит в конкретную семейную группу, и (с) устройство связано с этой конкретной семейной группы. Существуют многочисленные типы соотношений, например, описанные в этом примере, которые пользователи понимают интуитивно, и предпочтительные варианты осуществления описанных здесь систем и способов способны создавать системы, которые естественным образом понимают эти виды соотношений. Соотношения между сущностями можно создавать, уничтожать и изменять со временем, и предпочтительные варианты осуществления обеспечивают естественный способ определения прав в динамиче
- 32 012918 ской сетевой среде - среде, которую потребители могут естественным образом понимать. Тем не менее, если распространитель контента хочет использовать более традиционный подход к выражению прав, предпочтительные варианты осуществления могут охватывать и его. Например, можно использовать инструменты для перевода традиционных выражений прав в наборы объектов, например, описанных выше, и/или можно реализовать механизм ΌΚΜ, который работает непосредственно на таких выражениях прав. Альтернативно, в некоторых вариантах осуществления, устройства не понимают такие традиционные выражения прав, и не подчиняются их ограничениям.
Предпочтительные варианты осуществления описанных здесь систем и способов также имеют очень общее обозначение медиа-услуг. Широковещательная служба и интернет-служба загрузки или подписки являются примерами медиа-услуг. Ограничения, связанные с этими услугами, могут затруднять совместное использование контента. Согласно предпочтительным вариантам осуществления описанных здесь систем и способов, контент можно получать в рамках широковещательных, широкополосных и мобильных услуг, и совместно использовать в группе сетевых устройств в доме, включающей в себя портативные устройства. Альтернативно или дополнительно, услуги могут предоставляться отдельными устройствами в режиме взаимодействия равноправных устройств посредством беспроводной связи. Например, новое поколение сотовых телефонов с функцией \νίΕί может обеспечивать услуги каталогов контента для других устройств. Такая услуга позволяет другим устройствам видеть, что контент доступен для совместного использования от устройства. Услуга обеспечивает информацию, которую можно использовать для определения прав, что позволяет принимать или легко исключать любые ограничения.
Предпочтительные варианты осуществления описанных здесь систем и способов не ограничиваются одной услугой или одной платформой. Как объяснено выше, предпочтительные варианты осуществления способны работать с многочисленными услугами, в том числе персональными услугами. Это приобретает все большее значение по мере распространения домашних и персональных сетей. Например, в настоящее время доступны цифровые камеры с возможностью связи по \νίΕί. что создает большое удобство для распространения фотографий по сетям. Полезно иметь возможность автоматического распространения фотографий, но камере придется иметь дело со многими разными сетями по мере ее перемещения. Автоматизированное распространение удобно, но личные фотографии, конечно, являются личными. Варианты осуществления описанных здесь систем и способов позволяют легко распространять фотографии в семье на семейных устройствах, но не с любыми устройствами, которые могут встретиться камере в сети. В общем случае, чем больше устройств становятся сетевыми, тем важнее становится управлять правами на весь контент на этих устройствах. Хотя целью подключения к сети является обеспечение совместного использования информации на сетевых устройствах, сети будут перекрываться и сливаться друг с другом. Сети позволяют легко обеспечивать совместное использование контента, но его совместное использование не должно быть бесконтрольным. Таким образом, желательно иметь систему ΌΚΜ, которая адаптируется к сети и которая может использовать контекст, обеспечиваемый контентом, пользователем, сетью и характеристиками устройств, для определения, следует ли обеспечивать совместное использование контента и как это нужно делать. Предпочтительные варианты осуществления описанных здесь систем и способов обеспечивают такой подход.
6. Иллюстративная архитектура для потребления и упаковки контента.
Ниже приведено описание базовой архитектуры потребляющего приложения (например, медиапроигрывателя), которое потребляет ΌΚΜ-защищенный контент, и приложения упаковки (например, приложения, установленного на сервере), которое упаковывает контент, адресованный потребляющим приложениям.
6.1. Архитектура клиента.
Ниже приведен пример функций, которые механизм ΌΚΜ согласно иллюстративному варианту осуществления может осуществлять для приложения хоста, которое потребляет контент.
6.1.1. Интерфейс приложения хоста к механизму ΌΚΜ.
Хотя в предпочтительном варианте осуществления для механизмов ΌΚΜ не требуются ΑΡΙ, ниже приведены высокоуровневые описания разновидности интерфейса, обеспечиваемого иллюстративным механизмом ΌΚΜ (именуемым здесь механизмом ΌΚΜ ΟοΙοριίδ) к приложению хоста в одном иллюстративном варианте осуществления:
Ос1ори5::Слса1с8с55юп(1ю51Соп1сх1ОЬ)сс1) δβδδίοη.
Создает сеанс, заданный контекстом приложения хоста. Объект «контекст» используется механизмом ΌΚΜ Ос1ори5 для производства обратных вызовов в приложение.
8е881оп::Ргосе88ОЬ]ес1(6гтОЬ]ес1).
Эта функция должна вызываться приложением хоста, когда он сталкивается с определенными типами объектов в медиа-файлах, которые можно идентифицировать как принадлежащие подсистеме ΌΚΜ. Такие объекты включают в себя программы управления контентом, жетоны принадлежности и т.д. Синтаксис и семантика этих объектов непрозрачна для приложения хоста.
8е55юп::ОрепСоп1еп1(соп1еп1РеГегепсе) СоШеШ.
- 33 012918
Приложение хоста вызывает эту функцию, когда ему нужно взаимодействовать с файлом мультимедийного контента. Механизм ΌΚΜ возвращает объект Соп!еп!, который затем можно использовать для извлечения информации ΌΚΜ о контенте и взаимодействия с ним.
Соп!еп!::6еЮгт1п1о().
Возвращает метаданные ΌΚΜ о контенте, которые отсутствуют в обычных метаданных для файла. Соп1еп1::Сгеа1еЛсиоп(ас1юп1пГо) АсРоп.
Приложение хоста вызывает эту функцию, когда оно хочет взаимодействовать с объектом СоШеЩ. Параметр Лс1юп1пГо указывает, какого типа действие должно осуществлять приложение (например, воспроизведение), а также, если необходимо, любые связанные с ним параметры. Функция возвращает объект Лсйои, который затем можно использовать для осуществления действия и извлечения ключа контента.
Αсΐ^οи::6еΐΚеуIиГο().
Возвращает информацию, которая необходима подсистеме дешифрования для дешифрования контента.
Αсΐ^οи::Сйеск().
Проверяет, авторизует ли подсистема ΌΚΜ осуществление этого действия (т.е. будет ли выполнено Ас1юп::РегГогтО).
Ас1юп::РегГогтО.
Осуществляет действие и обеспечивает любые последствия (в том числе, побочные эффекты), согласно правилу, которое управляет этим действием.
6.1.2. Интерфейс механизма ΌΚΜ к услугам хоста.
Ниже приведен пример разновидности интерфейса услуг хоста, необходимый механизму ΌΚΜ, согласно иллюстративному варианту осуществления, от приложения хоста согласно иллюстративному варианту осуществления.
Но51СоЩех1::Се1Н1е8у51ет(1уре) И1е8у5!ет.
Возвращает виртуальный объект Ейе8у5!ет, к которому подсистема ΌΚΜ имеет эксклюзивный доступ. Этот виртуальный ЕПеЗуЧет можно использовать для сохранения информации состояния ΌΚΜ. Данные в этом ЕПеЗуЧет может читать и записывать только подсистема ΌΚΜ.
Но51СоЩех1::Се1СиггеЩТппеО.
Возвращает текущие дату/время, поддерживаемые системой хоста.
Но51СоЩех1::СеИбеЩ|1уО.
Возвращает уникальный ΙΌ этого хоста.
Но51СоЩех1::Ргосе55ОЬ)ес1(ба1аОЬ]ес1).
Передает обратно услугам хоста объект данных, который может быть внедрен в объект ΌΚΜ, но который подсистема ΌΚΜ идентифицировала как управляемый хостом (например, сертификаты).
Ηο8ΐСοиΐеxΐ::Vеπίу8^диаΐи^е(8^диаΐшсIиГο).
Проверяет действительность цифровой подписи на объекте данных. В одном варианте осуществления объект 5щпаШге1пГо содержит информацию, эквивалентную информации, найденной в элементе ΧΜβδί^. Услуги хоста отвечают за управление ключами и сертификатами ключей, необходимыми для удостоверения подписи.
Ηο8ΐСοиΐеxΐ::С^еаΐеС^рйе^(с^рйе^Туре, кеу1пГо) С1ркег.
Создает объект С1рйег, который подсистема ΌΚΜ может использовать для шифрования и дешифрования данных. Задается минимальный набор типов шифра, и для каждого из них реализация шифра требует формат для описания информации ключа.
С1рйег: :Епсгур1(ба1а).
С1рйег::Оесгур!(ба!а).
Но51СоЩех1::Сгеа1еОще51ег(бще51егТуре) ОщеЧег.
Создает объект ОщеЧег который подсистема ΌΚΜ может использовать для вычисления защищенного хэша на некоторых данных. В одном варианте осуществления, можно задать минимальный набор типов дайджеста.
О1де8!ег::ирба!е(ба!а).
П1де8!ег::6еЮ1де8!().
6.1.3. Диаграмма последовательности υΜΚ
На фиг. 26 показано использование иллюстративных ΑΡΙ, описанных в предыдущих разделах, и взаимодействия, которые имеют место между приложением хоста и механизмом клиента ΌΚΜ в иллюстративном варианте осуществления.
6.2. Иллюстративная архитектура упаковщика.
Ниже приведен пример функций, которые может осуществлять механизм упаковки для приложения хоста, которое упаковывает контент. На практике, приложение упаковки может конкретно предназначаться для упаковки, или составлять часть приложения общего назначения, действующего на пользовательской системе, которое также осуществляет доступ к защищенному контенту (упакованному локально
- 34 012918 или в другом месте, например, в сети).
6.2.1. Интерфейс приложения хоста к механизму упаковки.
В этом разделе приведено высокоуровневое описание иллюстративного ΑΡΙ между приложением хоста и механизмом упаковки, используемым в связи с иллюстративным механизмом ΌΚΜ, именуемым ОсЮрик.
Ос1орик::Сгеа1е8еккюп(1юк1Соп1ех1ОЬ]ес1) 8екмоп.
Создает сеанс для данного контекста приложения хоста. Объект «контекст», возвращаемый этой функцией, используется механизмом упаковки для осуществления обратных вызовов в приложение.
8екк1оп::Сгеа1еСоп1еп1(соп1еп1ВеГегепсек||) СоШеШ.
Приложение хоста вызывает эту функцию для создания объекта Соп1еп1 который будет связан с объектами «лицензия» на последующих этапах. Наличие более одной ссылки на контент в массиве соп1еп1ВеГегепсек подразумевает, что они связаны друг с другом в пучок (например, одна дорожка аудио и одна дорожка видео), и что выданная лицензия должна быть нацелена на них как на одну неделимую группу.
Соп1еп1::8е10гт1пГо(бгт1пГо).
Параметр бтбпГо указывает метаданные лицензии, которая будет выдана, бтбпГо выступает в роли руководства по трансляции лицензии в байт-код для виртуальной машины.
Соп1еп1::СеЮВМОЬ]ес1к(Гогта1) бгтОЬ)ес1к.
Эта функция вызывается, когда приложение хоста готово получить бгтОЬ)ес18, созданные механизмом упаковки. Параметр Гогта! указывает предполагаемый формат этих объектов (например, ХМЬ или двоичные атомы).
Соп1еп1::СеИ<еукО кеук[].
Эта функция вызывается приложением упаковки хоста, когда ему нужны ключи для шифрования контента. В одном варианте осуществления, существует по одному ключу для каждой ссылки на контент.
6.2.2. Интерфейс механизма упаковки к услугам хоста.
Ниже приведен пример типа интерфейса, который нужен иллюстративному механизму упаковки для обеспечения приложения хоста в одном варианте осуществления.
Нок1Соп1ех1::Се1Н1е8ук1ет(1уре) Н1е8ук1ет.
Возвращает виртуальный объект ЕПеЗуЦет, к которому подсистема ΌΚΜ имеет эксклюзивный доступ. Этот виртуальный ЕПеЗуйет можно использовать для сохранения информации состояния ΌΚΜ. Данные в этом ЕПе8ук1ет может читать и записывать только подсистема ΌΚΜ.
Нок1Соп1е\1::Се1Сиггеп1Т|теО Типе.
Возвращает текущие дату/время, поддерживаемые системой хоста.
Нок1Соп1ех1::Се11бепШуО ΙΌ.
Возвращает уникальный ΙΌ этого хоста.
НойСоШехЩРегГогтЗгдпаШге^дпаШгеЩо, ба1а).
Некоторые объекты ΌΚΜ, созданные механизмом упаковки, должны быть доверенными. Эта услуга, обеспеченная хостом, будет использоваться для подписывания указанного объекта.
НойСои1ех1::Сгеа1еС1рЬег(с1рЬегТуре, кеубпГо) С1р1ег.
Создает объект СарНег (объект, способный шифровать и дешифровать данные), который механизм упаковки может использовать для шифрования и дешифрования данных. В одном варианте осуществления, объект СарНег используется для шифрования данных ключа контента в объекте Соп1еп1Кеу.
СарНег: :Епсгур1(ба1а).
Шифрует данные.
С1рЬег::Иесгур1(ба1а).
Дешифрует данные.
Нок1Соп1ех1::Сгеа1еОщек1ег(бщек1егТуре) ЭщеЦег.
Создает объект ОщеЦег который механизм упаковки может использовать для вычисления защищенного хэша на некоторых данных.
Ощек1ег::ирба1е(ба1а).
Передает данные в объект ЭщеЦег.
Ощек1ег::Се1Ощек10.
Вычисляет дайджет.
Нок1Соп1ех1::Сепега1еВапботМ.1тЬегО.
Генерирует случайное число, которое можно использовать для генерации ключа.
На фиг. 27 показана диаграмма ИМЬ, демонстрирующая пример использования вышеописанных иллюстративных ΑΡΙ и взаимодействий, которые имеют место между приложением хоста и механизмом упаковки в одном иллюстративном варианте осуществления.
7. Объекты.
В этом разделе приведена дополнительная информация, относящаяся к объектам ΌΚΜ, которые
- 35 012918 служат строительными блоками иллюстративной реализации механизма ΌΚΜ. Сначала дадим сравнительно общий обзор типов объектов, которые механизм ΌΚΜ использует для защиты и администрирования контента. Затем приведем более подробное описание этих объектов и информации, которую они несут, а также некоторых иллюстративных структур данных, используемых в одном иллюстративном варианте осуществления.
7.1. Объекты ΌΚΜ для защиты и администрирования контента.
Как описано выше в связи с фиг. 6, объекты управления контентом (иногда именуемые, совместно с объектами «узел» и «связь», объектами ΌΚΜ) используются для связывания правил и условия пользования с защищенным контентом. Совместно, эти объекты образуют лицензию.
Согласно фиг. 6, данные, представленные объектом «контент» 614, зашифрованы с использованием ключа. Этот ключ, необходимый для дешифрования контента, представлен объектом Соп1еп1Кеу 602, и связь между контентом и ключом, используемым для его шифрования, представлена объектом «протектор» 604. Правила, которые регламентируют использование ключа дешифрования, представлены объектом управления 608, и связь между Соп1еп1Кеу 602 и объектом управления 608 представлена объектом «контроллер» 606. В одном варианте осуществления, доверенные системы используют ключ дешифрования контента только согласно правилам, выраженные байт-кодом в объекте управления 608. На фиг. 28А показана более подробная иллюстрация лицензии, например, показанной на фиг. 6, и показана схема подписи, которая используется в одном варианте осуществления.
7.1.1. Общие элементы.
В одном варианте осуществления, объекты совместно используют общие основные особенности: каждый из них может иметь ГО, список атрибутов и список расширений.
7.1.1.1. ГО.
Объекты, на которые ссылаются другие объекты, имеют уникальный ГО. В одном варианте осуществления ГО являются просто ИИ, и, по соглашению, эти ИИ являются υΚΝ.
7.1.1.2. Атрибуты.
Атрибуты являются типизированными значениями. Атрибуты могут быть именованными или безымянными. Имя именованного атрибута является простой строкой или ИК1. Значение атрибута является простым типом (строка, целое число или массив байтов) или составным типом (список или массив). Атрибуты типа 'список' содержат неупорядоченный список именованных атрибутов. Атрибуты типа 'массив' содержат упорядоченный массив безымянных атрибутов.
Поле 'айлЬкек' объекта является (возможно, пустой) неупорядоченной коллекцией именованных атрибутов.
7.1.1.3. Расширения.
Расширения это элементы, которые можно добавлять к объектам для переноса необязательных или обязательных дополнительных данных. Расширения являются типизированными и также имеют уникальные ГО. Расширения могут быть внутренними или внешними.
7.1.1.3.1. Внутренние расширения.
Внутренние расширения содержатся в объекте, которые они расширяют. Они имеют флаг 'спйсаТ, который указывает, необходима ли реализация, которая использует объект, знать конкретный тип данных расширения для расширения. В одном варианте осуществления, если реализация встречает объект с критическим расширением, имеющим тип данных, который она не понимает, она может отбросить весь объект.
В одном варианте осуществления, ГО внутреннего расширения должен быть локально-уникальным: объект не может содержать два расширения с одним и тем же ГО, но возможно, что два разных объекта содержат расширения с одинаковым ГО.
Поле 'ех1еп8юп8' объекта является (возможно, пустой) неупорядоченной коллекцией внутренних расширений.
7.1.1.3.2. Внешние расширения.
Внешние расширения не содержатся в объекте, который они расширяют. Они появляются независимо от объекта и имеют поле '5иЬ)есГ. которое содержит ГО объекта, который они расширяют. В одном варианте осуществления, ГО внешнего расширения должно быть глобально-уникальным.
7.1.2. Соп1еп1.
В одном варианте осуществления, объект «контент» является внешним объектом. Его формат и хранение не подчиняется механизму ΌΡΜ, но подчиняется подсистеме управления контентом приложения хоста (например, контент может представлять собой видео-файл МР4, музыкальный трек МР3 и т.д.). В одном варианте осуществления, формат контента нуждается в обеспечении поддержки связывания ГО с данными полезной нагрузки контента. Полезная нагрузка контента шифруется независимо от формата (обычно симметричным шифром, например ЛЕЗ).
7.1.3. Соп1еп1Кеу.
Объект Соп1еп1Кеу представляет уникальный ключ шифрования и связывает с ним ГО. ГО предназначен для того, чтоб объекты Рго1ес1ог и объекты Соп1го11ег могли ссылаться на объекты Соп1еп1Кеу. Данные фактического ключа, инкапсулированные в объекте Соп1еп1Кеу, сами зашифрованы, в результате
- 36 012918 чего их могут прочитать только получатели, авторизованные на дешифрование контента. Объект Соп1еп1Кеу указывает, какая криптосистема использовалась для шифрования данных ключа. Криптосистема, используемая для защиты данных ключа контента, называется системой распространения ключей. Можно использовать разные системы распространения ключей. Примером системы распространения ключей является вышеописанная система распространения ключей 8сиЬа.
7.1.4. Рго1есЮг.
Объект Рго1есЮг содержит информацию, которая позволяет определять, какой ключ использовался для шифрования данных объектов Соп1еп1. Он также содержит информацию, какой алгоритм шифрования использовался для шифрования этих данных. В одном варианте осуществления, объект Рго1ес1ог содержит один или несколько ΙΌ, которые являются ссылками на объекты С'оп1еп1 и в точности один ΙΌ, который является ссылкой на объект Соп1еп1Кеу, который представляет ключ, который использовался для шифрования данных. Если Рго1ес1ог указывает на более чем один объект СогИепк то все эти объекты Соп1еп1 представляют данные, которые были зашифрованы с использованием одного и того же алгоритма шифрования и одного и того же ключа. В одном варианте осуществления, пока используемая криптосистема позволяет безопасно использовать один и тот же ключ для разных элементов данных, не рекомендуется, чтобы объект Рго1ес1ог указывал на более чем один объект Соп1еп1.
7.1.5. Соп1го1.
Объект управления содержит информацию, которая позволяет механизму ΌΚΜ принимать решения относительно того, следует ли разрешить определенные действия над контентом, по запросу приложения хоста. В одном варианте осуществления, правила, которые регламентируют использование ключей контента, закодированы в объекте управления в виде байт-кода для выполнения виртуальной машиной. Объект управления также имеет уникальный ΙΌ, что позволяет объекту «контроллер» ссылаться на него. В одном варианте осуществления, объекты управления подписаны, благодаря чему механизм ΌΚΜ может удостовериться, что байт-код объекта управления является действительным и доверенным, прежде чем использовать его для принятия решений. Действительность объекта управления также, в необязательном порядке, можно выводить путем проверки защищенного хэша, содержащегося в объекте «контроллер».
7.1.6. Соп1го11ег.
Объект «контроллер» содержит информацию, которая позволяет механизму ΌΚΜ определять, какой объект управления регламентирует использование одного или нескольких ключей, представленных объектами Соп1еп11<еу. Объект «контроллер» содержит информацию, которая привязывает его к объектам Соп1еп1Кеу и объекту управления, на который он ссылается. В одном варианте осуществления, объекты «контроллер» подписываются (например, приложением упаковщика, который имеет сертификат, позволяющий ему подписывать объекты «контроллер»), что позволяет устанавливать действительность связи между СогИегиКеу и объектом управления, который управляет им, а также действительность связи между Соп1еп1Кеу ΙΌ и данными фактического ключа. Подпись объекта «контроллер» может представлять собой подпись открытым ключом или подпись симметричным ключом или их комбинацию. Кроме того, когда дайджест объекта управления, на который ссылается объект «контроллер», включен в объект «контроллер», действительность объекта управления можно вывести без необходимости отдельно проверять подпись объекта управления.
7.1.6.1. Подпись симметричным ключом.
В одном варианте осуществления это предпочтительный тип подписи для объектов «контроллер», и она реализуется путем вычисления Кода аутентификации сообщения (МАС) объекта «контроллер», снабженного тем же ключом, который представлен соответствующим объектом СоПепКеу. В одном варианте осуществления канонический метод для этого МАС предусматривает использование НМАС с тем же алгоритмом хэширования, который был выбран в качестве алгоритма подписи РК1, используемого в той же конфигурации.
7.1.6.2. Подпись открытым ключом.
Этот тип подписи используется, когда нужно знать идентичность сущности, подписывающей объект «контроллер». Этот тип подписи реализуется посредством алгоритма подписи открытым ключом, подписывания секретным ключом принципала, который утверждает действительность этого объекта. В одном варианте осуществления при использовании этого типа подписи подпись симметричным ключом также будет присутствовать и подписывать как объект «контроллер», так и подпись открытым ключом, что позволяет гарантировать, что принципал, подписавший своим секретным ключом, также знает фактическое значение ключа контента, переносимого объектом Соп1еп1<еу.
7.2. Объекты ΌΚΜ идентичности и управления ключами.
Как описано выше объекты «узел» представляют сущности в профиле ΌΚΜ, и никакой явной или неявной семантики не используется для определения того, что представляют объекты «узел». Данная конфигурация (профиль ΌΚΜ) системы определяет, какие существуют типы принципалов, и какие роли и идентичности представляют разные объекты «узел». Эта семантическая информация обычно выражается с использованием атрибутов объекта «узел».
Объекты «связь» представляют соотношения между узлами. Объекты «связь» также, в необязатель
- 37 012918 ном порядке, могут содержать некоторые криптографические данные, что позволяет использовать связь для вывода ключа контента. Как и для узлов, в одном варианте осуществления, никакой явной или неявной семантики используется для определения, что означает соотношение связи тсапз. В зависимости от того, что представляют начальный и конечный узлы связи в данном профиле ΌΒΜ, смысл соотношения связи может выражать принадлежность, собственность, ассоциацию и/или многие другие типы соотношений. В типичном профиле ΌΚΜ, некоторые объекты «узел» могут представлять пользователей, другие узлы могут представлять устройства, и прочие узлы могут представлять группы пользователей или авторизованные домены (ΆΌ). В таком контексте, связи между устройствами и пользователями могут представлять отношение собственности, и связи между пользователями и группами пользователей или доменами авторизации могут представлять отношения принадлежности. На фиг. 28В показана структура и взаимоотношение между узлами и связями в одном иллюстративном варианте осуществления.
7.2.1. Узел.
Объект «узел» представляет сущность в системе. Атрибуты объекта «узел» задают определенные аспекты того, что представляет объект «узел», например, роль или идентичность, представленную объектом «узел» в контексте профиля ΌΚΜ. Объект «узел» также может иметь пару асимметричных ключей конфиденциальности, которая используется для нацеливания конфиденциальной информации на подсистемы, имеющие доступ к конфиденциальным частям объекта «узел» (обычно, сущность, представленную узлом, или некоторую сущность, которая отвечает за управление этим узлом). Конфиденциальная информация, нацеленная на узел, может быть зашифрована открытым ключом конфиденциальности этого узла. Объект «узел» также может иметь пару асимметричных ключей совместного пользования, и симметричным ключом совместного пользования могут совместно использовать объекты «связь», когда система использует Систему вывода ключа контента для распространения ключей контента, например, описанную здесь в другом месте. В предпочтительном варианте осуществления, только сущностям, подлежащим ссылке со стороны объектов «связь» или «управление», или сущностям, которым необходимо принимать криптографически нацеленную информацию, нужно иметь соответствующие объекты «узел».
7.2.2. Связь.
Объект «связь» - это подписанное утверждение, что существует ориентированное ребро в графе, вершинами которого являются объекты «узел». Для данного множества узлов и связей, мы говорим, что существует путь между узлом X и узлом Υ, если существует ориентированный путь между вершиной узла X и вершиной узла Υ в графе. Когда существует путь между узлом X и узлом Υ, мы говорим, что узел Υ доступен от узла X. Утверждения, представленные объектами «связь», используются для выражения, какие узлы доступны от других узлов. Объекты управления, которые управляют объектами «контент», могут проверить, прежде чем разрешить осуществление действия, что определенные узлы доступны от узла, связанного с сущностью, осуществляющей действие. Например, если узел Ό представляет устройство, которое хочет осуществить действие воспроизведение на объекте «контент», объект управления, который управляет объектом «контент», может проверить, доступен ли определенный узел и, представляющий определенного пользователя, от узла Ό. Чтобы определить, доступен ли узел и, механизм ΌΚΜ может проверить, существует ли множество объектов «связь», которые могут установить путь между узлом Ό и узлом и.
В одном варианте осуществления, механизм ΌΚΜ проверяет объекты «связь» прежде, чем использовать их для принятия решения о наличии путей в графе узлов. В зависимости от конкретных особенностей системы сертификатов (например, χ509ν3), используемой для подписывания объектов «связь», объектам «связь» можно назначать ограниченные сроки действия, отменять их и т. д. В одном варианте осуществления, механизм ΌΚΜ непосредственно не имеет дела с политиками, определяющие, какие ключи могут подписывать объекты «связь», какие объекты «связь» можно создавать и срок действия объектов «связь». Вместо этого, эти политики используют информацию атрибутов узла. Для облегчения задачи применения определенных политик, в одном варианте осуществления предусмотрен способ расширения стандартных форматов сертификата с дополнительной проверкой ограничений. Эти расширения дают возможность выразить ограничения по действительности сертификатов для ключей, которые подписывают связи, благодаря чему ограничения, например, какие типы узлов соединяет связь, а также другие атрибуты, можно проверять прежде, чем признать связь действительной.
В одном варианте осуществления, объект «связь» может содержать объект управления, который будет использоваться для ограничения действительности связи. Кроме того, в одном варианте осуществления объект «связь» может содержать криптографические данные вывода ключа, которые снабжают пользователя ключами совместного пользования для распространения ключей. Эти криптографические данные содержат, помимо метаданных, личные и/или симметричные ключи совместного пользования начального узла, зашифрованные открытым ключом совместного пользования и/или симметричным ключом совместного пользования конечного узла.
7.3. Структуры данных.
В нижеследующих разделах описана более подробно иллюстративная модель объекта для объектов, рассмотренных выше, задающая поля, которые имеет объект каждого типа в одном иллюстративном варианте осуществления. Структуры данных описаны с использованием сравнительно простого синтаксиса
- 38 012918 описания объекта. Каждый тип объекта задается классом, который может расширять родительский класс (т.е. отношение это есть). Описания классов приведены в терминах простых абстрактных типов йппд (строки символов), ίηΐ (целочисленное значение), Ьу1с (8-битовое значение), и Ьоо1саи (истина или ложь), но не определяют никаких конкретных правил кодирования ни для этих типов данных, ни для составных структур, содержащих эти типы. Способ кодирования или представления объектов может варьироваться в зависимости от реализации механизма. На практике, данный профиль использования механизма ΌΚΜ может задавать, как представляются поля (например, с использованием схемы ХМЬ).
В одном иллюстративном варианте осуществления используются следующие обозначения:
«класс».
данных типом составной состоит одного полей.
нескольких простои которых имеет составной поле может быть отдельного типа.
однородный данных именуемым типом составной тип состоит ив О элементов одного типа пуст).
Простои тип: представляет строку символов
Простои целочисленное
Простои тип:
целочисленное
Простои истина «класс».
который другой который другой расширяет содержит поля помимо полей абстрактный «класс».
«класс» можно расширять, которые используются
Абстрактные
ГИЛЫ которые типы, когда список именуемого суперклассом
- 39 012918 £1е1д;}
Задает необязательное поле. Необязательное поле это поле.
которое можно исключить из составного типа данных, который его содержит (£уре ίΐβΐά;)
Задает поле, которое будет пропущено при вычислении каноническом последовательности байтов для заключения составного поля с1азз
5иЬС1азз ехГепаз Задает подкласс типа
5ирегС1азз (£χ61ά=ν31υθ) {...} «класс» и указывает, что для всех экземпляров этого подкласса, значение определенного поля суперкласса всегда равно фиксированному значению
7.3.1. Общие структуры.
В одном иллюстративном варианте осуществления используются следующие общие структуры: аЬз1гас( скза Ос1оЪ]есХ { {аСГ1п§ И;}
АНпЬи1е[] аЫпЬШез;
1п1ета1Ех£еп5юп[] ех1епзюп5;
} с1аз8 ТгапзСогт {
81ппз а1§ог№т;
} с!аз$ 01§ез1 {
ТгапзГогт[] КапзГогтз;
8Гпп£ а1§оп1кт;
Ьу1е[] уа!ие;
} с1азз КеГегепсе {
8ГГ1П£ ιό;
{ΟίβεϊΙ άϊ^βδί;} )
7.3.1.1. Атрибуты.
В одном варианте осуществления, существует четыре разновидности атрибутов: 1п(ецегА(1г1Ьи(е, §йшдАйпЬи1е, Ву1еАггауАйпЬи1е, и Ь181Айг1Ьи1е, каждый из которых имеет имя и тип.
аЬз!гас1 с1азз АйпЬи1е { {зШпд пате;}
8(τίη§ 1уре;
) с!азз 1п1е§егАИг|Ьиге ех1епс1з АйпЬи1е((уре=’;пГ) { ίηΐ уа!ие;
} с1азз 81г1п@АПпЬи1е ех1епбз АНпЬи1е(Хуре=’з1пп§’) {
3ΐτίη§ уа1ие;
} с1азз ВуйАггауАйпЬиК ех1епбз АипЬи1е((уре=’Ьу1е8’) {
Ьу1е[] уа1ие;
}
С1азз Ыз1АйпЬи1е ехкпбз АйпЬи1е(1уре=’НзГ) { АИпЬи1е[] аИпЬШез; И все должны быть именованными )
С1азз АггауАИпЪЫе ех1епбз АппЬи1е(1уре=’агтау’) { АйпЬи(е[] айпЪШез; // все должны быть безымянными
- 40 012918
7.3.1.2. Расширения.
В рассматриваемом иллюстративном варианте осуществления, существует два типа расширений: внутренние расширения, которые переносятся внутри Ос1оЬ|ес1. и внешние расширения, которые переносятся вне Ос1оЬ|ес1.____________________________________________________________________ аЬзСгасС с1азэ ЕхСепзЗопОаСа {
ЗСг1пд Суре;
} аЬзСгасС сЗазз ЕхСепзаоп { зСГ1пд ίά;
) сЗазз Ех£егпаЗЕхСепз1оп ехСепдз ЕхСепзЗоп { зСгЗпд зиЬдесС;
ЕхСепзЗопРаСа ЦаСа;
} с1азз 1пСегпаЗЕхСепзЗоп ехСепдз ЕхСеизгоп { Ьоо1еап сг1С1саЗ;
{РадезЬ даСаРЗдезС;} (ЕхСепзл-ОпРаСа <ЗаСа;) }_______________________________________________________________________________________________________
В некоторых вариантах осуществления, важно иметь возможность проверять подпись объекта, даже если данная реализация не понимает конкретный тип Ех1еи81оиОа!а. Таким образом, в одном варианте осуществления, добавляется уровень косвенности с полем йа!аО1де8!. Если спецификация Ех!еи81оиОа!а требует, чтобы данные были частью подписи в контексте конкретного объекта, то поле ФЦаОщеЦ будет присутствовать. Реализация, которая понимает этот тип Ех!еи81оиОа!а и потому способна вычислять его каноническое представление, может затем проверить дайджест. Если, в этом варианте осуществления, спецификация этого типа Ех!еи81оиОа!а чтобы данные не были частью подписи, то поле 4а!аО1де8! будет отсутствовать.
7.3.2. Объекты Ыобе с1азз Коде ехСепдз ОсСоЬдесС ( }
7.3.3. Объекты Ыик сЗазз Ыпк ехСепдз ОсСоЬдесС { зСгспд ίΓοτηΙά;
зСг1пд СоШ;
{СопСго1 сопСгоЗ;) _________________)__________________________________________________________________________________________________________________________________________________
7.3.4. Объекты Сои!го1 с1азз СопСгоЗ ехСепдз ОсСоЬдесС {
8Сг1пд ргоСосо1;
зСгхпд Суре; ЬуСе [] сойеМодиЗе;
_______________}__________________________________________________________________________________________________________________________________
7.3.5. Объекты Сои!еи!Кеу аЬзСгасС сЗазз Кеу { зСгЗпд ίά; зСгЗпд изаде; зСгхпд £огшаС; ЬуСе[] даСа;
} аЬзСгасС сЗазэ Ра1гедКеу ехСепда Кеу ( зСгапд раЗгТй;
} сЗазз СопсепСКеу ехСепдз ОсСоЬ^есС (
Кеу зесгеСКеу;
_______________)__________________________________________________________________________________________________________________________________
В одном варианте осуществления, каждый ключ имеет уникальный ίά, формат, использование (которое может быть пустым), и данные. Поле 'икаде', если оно не пусто, указывает, с какой целью можно использовать ключ. Для нормальных ключей контента, это поле пусто. Согласно вариантам осуществления, в которых используется схема распространения ключей, например, вышеописанная, это поле может указывать, является ли ключ ключом совместного пользования или ключом конфиденциальности. Поле 'ГогтаГ указывает формат поля Да!а' (например, 'КА^' для симметричных ключей или 'РКС8#8' для секретных ключей К8А и т.д.). Поле '4а!а' содержит данные фактического ключа, форматированные в соответствии с полем 'Гогта!'.
- 41 012918
Для ключей, которые входят в состав пары ключей (например, ключей К8Л), дополнительное поле 'ра1гИ' дает уникальный идентификатор пары, что позволяет ссылаться на пару из других структур данных.
В одном варианте осуществления поле данных в объекте «ключ» является незашифрованным значением фактического ключа (т.е. это незашифрованное значение ключа, которое будет хэшировано), даже если фактическое представление объекта содержит зашифрованную копию ключа.
7.3.6. Объекты Соп!то11ет.
с1азз СопТгоИег ех£епйз ОсСоЬзесЬ {
Ке£ёгепсе сся1£го1Ке£; Ке£егепсе[] соп£еп£КеуКе£з;
_______________}___________________________________________________________________________________________________________________________________________
8. Виртуальная машина.
Предпочтительные варианты осуществления описанного здесь механизма ΌΚΜ используют виртуальную машину (иногда именуемую здесь виртуальной машиной управления, УМ управления или просто УМ) для выполнения программ управления, которые регламентируют доступ к контенту. Ниже описаны иллюстративные варианты осуществления такой виртуальной машины, но этот иллюстративный вариант осуществления допускает различные модификации и изменения конструкции. Описано также объединение иллюстративного варианта осуществления виртуальной машины (именуемой здесь виртуальной машиной Р1апк!оп) с иллюстративным вариантом осуществления механизма ΌΚΜ (именуемого здесь Ос!ори8). Очевидно, однако, что варианты осуществления механизма управления цифровыми правами, архитектура и другие описанные здесь системы и способы можно использовать с любой подходящей виртуальной машиной или, в некоторых вариантах осуществления, вообще без виртуальной машины, и, таким образом, очевидно, что представленные ниже детали, касающиеся иллюстративных вариантов осуществления виртуальной машины, предназначены для иллюстрации, но не ограничения.
В предпочтительном варианте осуществления, УМ управления это традиционная виртуальная машина, которую легко реализовать с использованием различных языков программирования с очень малым объемом кода. Она основана на простом наборе команд со стековой организацией, построенном исходя из минимализма, без чрезмерной концентрации на скорости выполнения или плотность кода. В случаях, когда требуется компактный код, можно использовать методы сжатия данных для сжатия байт-кода виртуальной машины.
В предпочтительных вариантах осуществления виртуальная машина управления призвана быть пригодной в качестве конечного продукта для языков программирования низкого или высокого уровня, и поддерживает ассемблер, С и ЕОКТН. Кроме того, очевидно, что компиляторы для других языков, например, 1ауа или специализированных языков, можно создавать относительно прямым путем для компиляции кода в формат (например, байт-код), используемый виртуальной машиной. В одном варианте осуществления виртуальная машина управления предназначена для размещения в среде хоста, а не для выполнения непосредственно на процессоре или в логических устройствах. В предпочтительных вариантах осуществления, естественной средой хоста для виртуальной машины является механизм ΌΚΜ, хотя очевидно, что описанную здесь архитектуру виртуальной машины можно, альтернативно или дополнительно, использовать в других контекстах.
На фиг. 29 показана операционная среда иллюстративной реализации виртуальной машины управления 2902. Согласно фиг. 29 в одном варианте осуществления виртуальная машина 2902 выполняется в контексте своей среды хоста 2904, которая реализует некоторые функции, необходимые виртуальной машине для выполнения программ 2906. Обычно УМ управления выполняется в механизме ΌΚΜ 2908, который реализует ее среду хоста. Согласно фиг. 29, в предпочтительной базе данных, виртуальная машина 2902 и механизм ΌΚΜ 2908 обращаются к защищенной базе данных 2910 для постоянного хранения информации состояния.
8.1. Архитектура.
8.1.1. Модель выполнения.
В предпочтительных вариантах осуществления, УМ выполняет программы путем выполнения команд, записанных в виде байт-кода в кодовых модулях. Некоторые из этих команд могут вызывать функции, реализованные вне самой программы, осуществляя системные вызов. Системные вызовы можно реализовать на самой УМ или делегировать среде хоста.
В одном варианте осуществления УМ выполняет команды, записанные в кодовых модулях, в виде потока байт-кодов, загружаемых в память. УМ поддерживает виртуальный регистр, именуемый Ргодгат ОоиШег (РС) [счётчик команд], который увеличивается по мере выполнения команд. УМ выполняет все команды по очереди, пока не встретит команду ОР_8ТОР, команду ОР_КЕТ с пустым стеком вызова, или не возникнет исключение среды выполнения. Безусловные переходы указаны либо как относительный переход (указанный в виде байтового сдвига от текущего значения РС), либо как абсолютный адрес.
8.1.2. Модель памяти.
В одном варианте осуществления УМ использует сравнительно простую модель памяти, в которой память делится на память для хранения данных и кодовую память. Например, память для хранения дан
- 42 012918 ных можно реализовать как единое, плоское, непрерывное пространство памяти, начинающееся по адресу 0, и можно реализовать как массив байтов, выделенный в динамической памяти приложения хоста или среды хоста. В одном варианте осуществления, попытки обратиться к памяти за пределами выделенного пространства будут приводить к исключению среды выполнения, которое приведет к завершению выполнения программы.
Память для хранения данных может распределяться между несколькими кодовыми модулями, одновременно загружаемыми виртуальной машиной. К данным в памяти для хранения данных можно обращаться посредством команд обращения к памяти, которые, в одном варианте осуществления, могут обеспечивать 32-разрядный или 8-разрядный доступ. 32-разрядные обращения к памяти осуществляются с использованием обратного порядка следования байтов. В предпочтительном варианте осуществления, не делается никаких предположений относительно выравнивания между памятью, которую видит виртуальная машина, памятью, управляемой хостом (т.е. виртуальной или физической памятью ЦП хоста).
В одном варианте осуществления, кодовая память представляет собой плоское, непрерывное пространство памяти, начинающееся по адресу 0, и можно реализовать как массив байтов, выделенный в динамической памяти приложения хоста или среды хоста.
νΜ может поддерживать загрузку более одного кодового модуля. Если νΜ загружает несколько кодовых модулей, в одном варианте осуществления все кодовые модули совместно используют одну и ту же память для хранения данных (хотя данные каждого модуля предпочтительно загружать по разным адресам), но каждый из них имеет свою собственную кодовую память, что не дает команде перехода в одном кодовом модуле вызвать переход к коду в другом кодовом модуле.
8.1.3. Стек данных.
В одном варианте осуществления, νΜ имеет так называемый стек данных, который представляет 32-битовые ячейки данных, хранящиеся в памяти для хранения данных. νΜ поддерживает виртуальный регистр, именуемый 8(аск Рош(ег [Указатель стека] (8Р). После сброса, 8Р указывает на конец памяти для хранения данных, и стек растет вниз (при проталкивании данных в стек данных, регистр 8Р уменьшается). 32-битовые ячейки данных в стеке интерпретируются либо как 32-битовые адреса, либо как 32битовые целые, в зависимости от команды, ссылающейся на данные стека. Адреса являются беззнаковыми целыми. В одном варианте осуществления, все остальные 32-битовые целочисленные значения в стеке данных интерпретируются как знаковые целые, если не указано обратное.
8.1.4. Стек вызова.
В одном варианте осуществления, νΜ управляет стеком вызова, который используется для вызова подпроцедур. В одном варианте осуществления, команды обращения к памяти не могут непосредственно считывать или записывать значения, протолкнутые в этот стек. Этот стек используется внутри νΜ при выполнении команд ОР_18К, ОР_18КК и ОР_КЕТ. Для данной реализации νΜ, размер этого стека адресов возврата может быть задан минимальным, в результате чего будет разрешено лишь определенное количество вложенных вызовов.
8.1.5. Псевдорегистры.
В одном варианте осуществления, νΜ резервирует небольшое пространство адресов в начале памяти для хранения данных для отображения псевдорегистров. В одном варианте осуществления, адреса этих псевдорегистров фиксированы. Например, можно задать следующие регистры:
Адрес Размер Имя Описание
| 0 | 4 | 10 | 32-битовый | Ю |
| выполняющегося в данный | ||||
| момент сегмента кода. | νΜ | |||
| выбирает этот Ю | при | |||
| загрузке модуля. | ΫΜ | |||
| изменяет этот регистр | при | |||
| переходе от сегмента | кода | |||
| одного модуля к сегменту | ||||
| кода другого модуля | ||||
| 4 | 4 | 03 | 32-битовое значение, |
заданное равным абсолютному адресу данных, по которому загружен сегмент данных выполняющегося в данный
- 43 012918 модуля.
Это
С8 им момент значение загрузчиком
32-битовое заданное абсолютному по определяется модулей УМ значение.
равным адресу кода, которому загружен сегмент кода выполняющегося момент модуля.
данный
Это значение определяется
| загрузчиком модулей УМ | ||
| 32-битовое | значение, | |
| заданное | равным | |
| абсолютному адресу данных | ||
| первого | байта | после |
| области | пространства | |
| памяти | для | хранения |
| данных, | куда | загружены |
| сегменты | данных | кодовых |
| модулей. |
8.1.6. Карта памяти.
Ниже показана компоновка памяти для хранения данных и кодовой памяти в иллюстративном ва рианте осуществления.
Память для хранения данных
приложением незаданным.
виртуальном реализация одного или модулей, загруженных виртуальном машиной.
используемое
Данные кодовых данных пространство.
данных конец пространства последний пространства памяти для хранения данных.
памяти хранения данных основании требовании содержащихся кодовом модуле может использовать
- 44 012918
Кодовая память.
Диапазон адресов Описание
0-С8-1 Не задан. Виртуальная машина может загружать сегменты кода кодовых модулей по любому адресу от 0 и выше. Если она выбирает адрес больше О, использование пространства адресов от 0 до СЗ остается незаданным. Это означает, что
| виртуальная | машина | может | |
| использовать | его по | своему | |
| усмотрению, | |||
| СЗ-СЗ+размер | Образ сегмента кода | кодового |
(сегмент ксда)-1 модуля, загруженного виртуальной машиной
8.1.7. Выполнение процедур.
До выполнения кодовой процедуры, в одном варианте осуществления реализация виртуальной машины сбрасывает указатель стека данных, чтобы он указывал вершину инициализированного стека данных. Инициализированный стек данных содержит входные данные процедуры и доходит до конца памяти для хранения данных. Инициализированный стек данных можно использовать для передачи входных аргументов процедуре. В отсутствие инициализированного стека данных, указатель стека данных указывает на конец памяти для хранения данных. В одном варианте осуществления, начальный стек вызова либо пуст, либо содержит единый конечный адрес возврата, указывающий на команду ОР_8ТОР, что принудительно прекращает выполнение процедуры по команде ОР_8ТОР в случае, когда процедура заканчивается командой ОР_КЕТ.
Когда выполнение останавливается, либо вследствие выполнения конечной команды ОР_КЕТ с пустым стеком вызова, либо вследствие выполнения конечной команды ОР_8ТОР, любые данные, оставшиеся в стеке данных, считаются выходом процедуры.
8.1.8. Исключения среды выполнения.
В одном варианте осуществления, любое из следующих условий считается исключением среды выполнения, которое приводит к немедленной остановке выполнения:
попытка обращения к памяти для хранения данных за пределами текущего пространства адресов памяти для хранения данных;
попытка задать РС равным или вызвать переход РС к адресу кода за пределами текущего пространства адресов кодовой памяти;
попытка выполнения незаданного байт-кода;
попытка выполнения команды ОР-ϋΓν с операндом «вершина стека», равным 0; попытка выполнения команды ОР_МОЭ с операндом «вершина стека», авным 0; переполнение или опустошение стека вызова.
8.2. Набор команд.
В одном варианте осуществления, νΜ управления использует сравнительно простой набор команд. Хотя и ограниченный, этот набор команд достаточен для выражения программ любой сложности. Команды и их операнды представлены потоком байт-кодов. В одном варианте осуществления, набор команд работает со стеком, и, за исключением команды ОР_РИ8Н, ни одна из команд не имеет прямых операндов. Операнды считываются из стека данных, и результаты проталкиваются в стек данных. В одном варианте осуществления, νΜ является 32-разрядной νΜ: все команды работают с 32-разрядными стековыми операндами, представляющими либо адреса памяти, либо знаковые целые. Знаковые целые представлены двоичным кодированием с дополнением двойки. Иллюстративный вариант осуществления набора команд для использования с νΜ управления показан в нижеследующей таблице. В таблице, стековые операнды для команд с двумя операндами представлены как А, В, где операнд на вершине стека указан последним (т.е. В). Если не указано обратное, термин проталкивание, используемый в нижеследующем описании одного иллюстративного варианта осуществления, означает продвижение 32битового значения к вершине стека данных.
- 45 012918
| Код операции | Имя | Байт- код | Операнды | Описание |
| ОРД4ОР | Нет операций | 0 | Ничего не делает | |
| ΟΡ_ΡΌ8Η | Проталкивание константы | 1 | N (прямой) | Проталкивает 32-битовую константу |
| ΟΡϋΚΟΡ | Сброс | 2 | Удаляет верхнюю ячейку стека данных | |
| ордэир | Дублирование | 3 | Дублирует верхнюю ячейку стека данных | |
| Код операции | Имя | Байт- код | Операнды | Описание |
| ОР_8\¥АР | Обмен | 4 | Меняет местами две ячейки стека данных | |
| ОРАОО | Сложение | 5 | А, В | Проталкивает сумму А и В (А+В) |
| ор-Миь | Умножение | 6 | А, В | Проталкивает произведение А и В (А*В) |
| ор_зив | Вычитание | 7 | А, В | Проталкивает разность между А и В (А-В) |
| ορ_υιν | Деление | 8 | А, В | Проталкивает частное от деления А на В (А/В) |
| ОРМСЮ | Модуль | 9 | А, В | Проталкивает А по модулю В (А%В) |
| 0Ρ-ΝΕ6 | Отрицание | 10 | А | Проталкивает отрицание с дополнением 2 для А (А) |
| ОР_С’МР | Сравнение | 11 | А, В | Проталкивает -1, если А меньше В, 0, если А равно В, и 1, если А больше В |
| ΟΡ_ΑΝϋ | И | 12 | А, В | Проталкивает побитовое И для А и В (А & В) |
| ОРОН | Или | 13 | А, В | Проталкивает побитовое ИЛИ для А и В (А | В) |
| ОРХОК | Исключающее ИЛИ | 14 | А, В | Проталкивает побитовое исключающее ИЛИ для А и В (А Λ В) |
| ΟΡ_ΝΟΤ | Логическое отрицание | 15 | А | Проталкивает логическое отрицание А (1, если А равно 0, и 0, если А не равно 0) |
| ОР_8НЬ | Сдвиг влево | 16 | А, В | Проталкивает А, логически сдвинутое влево на В битов (А « В) |
- 46 012918
| ОР8НК. | Сдвиг вправо | 17 | А, В | Проталкивает А, логически сдвинутое вправо на В битов (А » В) |
| ОРДМР | Переход | 18 | А | Переход к А |
| ΟΡ_.ΤδΚ | Переход к | 19 | А | Переход к подпроцедуре |
| подпроцедуре | по абсолютном адресу А. Текущее значение РС проталкивается в стек | |||
| вызова. | ||||
| ΟΡΊδΚΚ | Переход к | 20 | А | Переход к подпроцедуре |
| подпроцедуре | по адресу РС+А. Текущее | |||
| (относительный) | значение РС | |||
| проталкивается в стек | ||||
| вызова. | ||||
| ΟΡ_ΚΕΤ | Возврат из | 21 | Возврат из подпроцедуры | |
| подпроцедуры | по адресу возврата, | |||
| вытолкнутому из стека | ||||
| вызова. | ||||
| ΟΡ_ΒΚΑ | Переход всегда | 22 | А | Переход к РС + А |
| ΟΡ-ΒΚΡ | Переход при | 23 | А, В | Переход к РС+В, если А > |
| положительном | 0 | |||
| значении | ||||
| ΟΡ_ΒΚΝ | Переход при | 24 | А, В | Переход к РС+В, если А < |
| отрицательном | 0 | |||
| значении | ||||
| ΟΡΒΚΖ | Переход при | 25 | А, В | Переход к РС+В, если А |
| нулевом | равно 0 | |||
| значении | ||||
| ΟΡ_ΡΕΕΚ | Считывание | 26 | А | Проталкивает 32-битовое значение по адресу А |
| ΟΡ_ΡΟΚΕ | Запись | 27 | А, В | Сохраняет 32-битовое |
| ΟΡ_ΡΕΕΚΒ | Считывание | 28 | А | значение А по адресу В Считывает 8-битовое |
| байта | значение по адресу А, | |||
| дополняет его нулями до | ||||
| 32 битов и проталкивает | ||||
| его в стек данных | ||||
| ΟΡ_ΡΟΚΕΒ | Запись байта | 29 | А, В | Сохраняет 8 младших битов значения А по адресу В |
| ор_ризнзр | Проталкивание | 30 | Проталкивает значение | |
| указателя стека | δΡ | |||
| ΟΡ_ΡΟΡ3Ρ | Выталкивание | 31 | А | Задает значение δΡ |
| указателя стека | равным А | |||
| ОРСАБЕ | Системный | 32 | А | Осуществляет системный |
| вызов | вызов с индексом А | |||
| орзтор | Останов | 255 | Прекращает выполнение |
- 47 012918
8.3. Кодовые модули.
В предпочтительном варианте осуществления кодовые модули хранятся в атомарном формате, аналогичном или идентичном тому, который используется для файлов МРЕС-4, и атомы содержат 32битовый размер (например, представленный 4 байтами в обратном порядке следования байтов), после которого следует 4-байтовый тип (например, байты, соответствующие значениям А8С11 для букв алфавита), после которого следует полезная нагрузка (например, 8 байтов).
На фиг. 30 показан формат иллюстративного кодового модуля 3000. Согласно фиг. 30, атом ркСМ 3002 является атомом верхнего уровня кодового модуля. Он содержит последовательность податомов. В одном варианте осуществления, атом ркСМ 3002 содержит один атом ркЭ8 3004, один атом ркС8 3006, один атом ркЕХ 3008, и, возможно, один атом ркКЦ 3010. Фтом ркСМ 3002 также может содержать любое количество других атомов, которые, в одном варианте осуществления, игнорируются, если присутствуют. В одном варианте осуществления, порядок податомов не указан, поэтому реализации не обязаны предусматривать конкретный порядок.
8.3.1. Атом ркЭ8.
Согласно фиг. 30, атом ркЭ8 3004 содержит образ памяти 3005 сегмента данных, который может загружаться в память для хранения данных. Согласно фиг. 31А, в одном варианте осуществления образ памяти 3005 представлен последовательностью байтов 3112, состоящей из одного байта заголовка 3114, после которого следует ноль или более байтов данных 3116. Байт заголовка 3114 кодирует номер версии, который идентифицирует формат следующих байтов 3116.
В одном варианте осуществления, задается только один номер версии (т.е. Оа1а8едтеп1Еогта1Уег8юп=0), и в этом формате байты данных образа памяти представляют необработанный образ, подлежащий загрузке в память. Загрузчик виртуальной машины загружает только байты данных 3116 образа памяти 3105, не включающие в себя байт заголовка 3114. В одном варианте осуществления, загрузчик виртуальной машины способен отказываться загружать образ в любом другом формате.
8.3.2. Атом ркС8.
Согласно фиг. 30, атом ркС8 3006 содержит образ памяти 3007 сегмента кода, который может загружаться в кодовую память. Согласно фиг. 31В в одном варианте осуществления образ памяти 3007 представлен последовательностью байтов 3120, состоящей из одного байта заголовка 3122, после которого следует ноль или более байтов данных 3124. Байт заголовка 3122 кодирует номер версии, который идентифицирует формат следующих байтов 3124.
В одном варианте осуществления задается только один номер версии (т.е. Со6е8едтеп(Еогта1Уег8юп=0), и, согласно фиг. 31С, в этой версии байт, следующий за байтом заголовка 3122, содержит еще один байт заголовка 3130, содержащий номер версии, который идентифицирует кодирование в виде байт-кода следующих байтов 3132. В примере, показанном на фиг. 31С, байт заголовка 3130 идентифицирует Ву1еС.'о6еУег8юп=0. который указывает, что байты данных 3132 содержат необработанную последовательность байтов со значениями байт-код, например, заданными в вышеописанном иллюстративном наборе команд. В предпочтительном варианте осуществления, загрузчик виртуальной машины загружает только часть 3132 байт-кода, состоящую из байтов данных, но не два байта заголовка 3122, 3130.
8.3.3. Атом ркЕХ.
Согласно фиг. 30, атом ркЕХ 3008 содержит список элементов экспорта. В примере, показанном на фиг. 30, первые четыре байта 3009 атома ркЕХ 3008 кодируют 32-битовое беззнаковое целое в обратном порядке следования байтов, равное количеству последующих элементов. Согласно фиг. 31Ό, каждый следующий элемент экспорта 3160 состоит из имени, кодированного одним байтом 3162, содержащим размер имени, 8, после которого следует 8 байтов 3164, содержащих А8СП-символы имени, включая оконечный нуль 3166, после которых следует 32-битовое беззнаковое целое 3168 в обратном порядке следования байтов, представляющее байтовый сдвиг именованной точки входа, измеряемый от начала данных байт-кода, хранящихся в атоме ркС8. На фиг. 31Е показан пример элемент 3170 таблицы экспорта для точки входа ΜΑΙΝ со сдвигом 64, в котором первый байт 3172 указывает, что размер имени (т.е. ΜΑΙΝ), плюс оконечный нуль, равен пяти байтам, и в котором последние четыре байта 3174 указывают, что байтовый сдвиг равен 64.
8.3.4. Атом ркКр.
Согласно фиг. 30, атом ркКЦ 3010 содержит требования, которым должна удовлетворять реализация виртуальной машины для выполнения кода в кодовом модуле. В одном варианте осуществления, этот атом является необязательным, и, если он отсутствует, виртуальная машина использует настройки реализации, принятые по умолчанию, которые, например, могут быть заданы профилем реализации.
В одном варианте осуществления, атом ркКЦ состоит из массива 32-битовых беззнаковых целочисленных значений, по одному на каждое поле:
- 48 012918
Имя поля Описание νπινθΓ^ίοη Ю версии спецификации УМ т1пОаРаМепюгу31ге Минимальный размер в байтах памяти для хранения данных, доступной коду. Она включает в себя память для хранения данных, используемую для загрузки образа сегмента данных, а также память для хранения данных, используемую стеком данных. В одном варианте осуществления, УМ должна отказываться загружать модуль, если он не может удовлетворить этому требованию тзпСаИЗбаскОерРЙ Минимальное количество вложенных вызовов подпроцедуры (ОР_Ц5В и ΟΡ_σ5ΒΒ), которое должна поддерживать УМ. В одном варианте осуществления, УМ должна отказываться
Г1адз загружать модуль, если он не может удовлетворить этому требованию.
Набор битовых флагов, представляющих необходимые особенности УМ,
В одном варианте осуществления, реализация УМ должна отказываться загружать кодовый модуль, в котором задан какой-либо неизвестный флаг. Например, если не задано ни одного флага, в одном варианте осуществления, реализация УМ должна проверить, что это поле задано равным 0.
8.3.5. Загрузчик модулей.
Виртуальная машина отвечает за загрузку кодовых модулей. При загрузке кодового модуля, образ памяти сегмента данных, закодированный в атоме ркЭ8, загружается по адресу памяти в память для хранения данных. Этот адрес выбирает загрузчик νΜ, и он хранится в псевдорегистре Ό8 при выполнении кода.
При загрузке кодового модуля выполняется особая процедура под названием 61оЬа1.ОпЬоа6, если эта процедура найдена среди элементов таблицы экспорта. Эта процедура не берет никаких аргументов в стеке и возвращает целочисленный статус по возвращении, причем 0 обозначает успех, и отрицательный код ошибки обозначает условие ошибки.
При выгрузке кодового модуля (или когда виртуальная машина, загрузившая модуль, избавляется от него), выполняется особая процедура под названием «61оЬа1.ОпИп1оа6, если эта процедура найдена
- 49 012918 среди элементов таблицы экспорта. Эта процедура не берет никаких аргументов в стеке, и возвращает целочисленный статус по возвращении, причем 0 обозначает успех, и отрицательный код ошибки обозначает условие ошибки.
8.4. Системные вызовы.
Программы виртуальной машины могут вызывать функции, реализованный вне сегмента кода ее кодовых модулей. Это делается с использованием команды ОР_СЛЬЬ, которая берет целочисленный стековый операнд, указывающий номер системного вызова, который должен быть сделан. В зависимости от системного вызова, реализация может представлять собой процедуру байт-кода в другом кодовом модуле (например, библиотеке функций утилит), исполняемую непосредственно на УМ в родном формате реализации УМ, или делегируемую внешнему программному модулю, например, среде хоста УМ.
В одном варианте осуществления, если команда ОР_СЛЬЬ выполняется с операндом, который содержит число, которое не соответствует никакому системному вызову, УМ ведет себя так, как если бы был сделан системный вызов 8Υ8_ΝΟΡ.
8.4.1. Выделение номеров системного вызова.
В рассматриваемом иллюстративном варианте осуществления, номера системного вызова от 0 по 1023 зарезервированы для фиксированных системных вызовов (эти системные вызовы будут иметь один и тот же номер во всех реализациях УМ). Номера системного вызова с 1024 по 16383 доступны УМ для динамического присвоения (например, номера системного вызова, возвращаемые Зуйеш.ЕшбЗуйеш Са11ΒуNате, могут динамически выделяться УМ и не обязаны быть одинаковыми номерами во всех реализациях УМ).
В одном иллюстративном варианте осуществления указаны следующие фиксированные номера системного вызова:
| Мнемокод | Номер | Системный вызов |
| 3Υ3_ΝΟΡ | 0 | ЗузЪет. ЫоОрегаЪл-Оп |
| 3¥3_ЕЕВиС_РК1МТ | 1 | ЗузЕет.ОеЬидРгхпЕ |
| 3¥3_Е1МС_ЗУЗТЕМСАЬЬ_ВУ_НАЕЕ | 2 | ЗузЕет. ПпдЗузЪетСаИВ уГОате |
| 3Υ3_3Υ3ΤΕΜ_ΗΟ3Τ_5ΕΤ_0ΒσΕ0Τ | 3 | ЗузЕет.НозГ..СеРОЬзесС |
| 5Υ5_5Υ3ΤΕΜ_ΗΟ3Τ_8ΕΤ_ΟΒσΕ<7Τ | 4 | ЗузЕет. НозЕ. ЗеГОЬзесР |
8.4.2. Стандартные системные вызовы.
В одном варианте осуществления поддерживается несколько стандартных системных вызовов, которые полезны для записи программ управления. Эти вызовы включают в себя системные вызовы с фиксированными номерами, перечисленные в вышеприведенной таблице, а также системные вызовы, имеющие динамически определяемые номера (т.е. их номера системного вызова извлекаются путем осуществления системного вызова 8у81еш.Ешб8у81ешСа11Ву№ше, которому в качестве аргумента передаются их имена).
В одном варианте осуществления системные вызовы, указанные в этом разделе, которые могут возвращать отрицательный код ошибки, могут возвращать коды ошибки с любым отрицательным значением. В разделе 8.4.4 указаны конкретные иллюстративные значения. В одном варианте осуществления, если возвращаются отрицательные значения кода ошибки, которые заранее не заданы, они интерпретируются как общее значение кода ошибки ЕЛГБиКЕ.
8у51еш.№Орега1юп. Этот вызов не берет никаких аргументов и ничего не возвращает, и просто завершается, ничего не сделав. Он используется, в основном, для тестирования УМ.
Зуйеш.ПеЬидРгшГ Этот вызов берет в качестве аргумента из вершины стека адрес ячейки памяти, содержащей строку, оканчивающуюся символом конца строки, и ничего не возвращает. Вызов этой функции приводит к печати строки текста в выходе отладки, что может быть полезно при отладке. Если реализация УМ не предусматривает возможности вывода текста отладки (что, например, может иметь место в среде без разработки), УМ может игнорировать вызов и интерпретировать его как Зук1е1п.№ОрегаВоп.
8у81еш. Е^пά8у8ΐешСа11ВуNате. Этот вызов находит номер системного вызова по его имени. Вызов берет в качестве аргумента (из вершины стека) адрес строки Л8СП, оканчивающейся символом конца строки, содержащей имя искомого системного вызова, и возвращает (в вершину стека) номер системного вызова, если системный вызов с указанным именем реализован, ΕΚίΚΟΚ_NΟ_8υСН_ПΈΜ, если системный вызов не реализован, и отрицательный код ошибки в случае возникновения ошибки.
8у81еш.Но81.Се1Еоса1Т1ше. Этот вызов не берет никаких аргументов и возвращает, в вершину стека, текущее значение местного времени хоста, которое, в одном варианте осуществления, выражается 32битовым знаковым целым, равным числу минут, прошедших с 00:00:00 1 января 1970 г., или отрицательным кодом ошибки.
5у81е1п.Но81.Се1Еоса1ТипеОП'8е1. Этот вызов не берет никаких аргументов и возвращает, в вершину
- 50 012918 стека, текущее смещение по времени (относительно времени ИТС) хоста, которое, в одном варианте осуществления, выражается 32-битовым знаковым целым, равным числу минут, составляющему разницу между местным временем и временем ИТС (т.е. ЬосаТЛте - ИТС).
8у81ет.Но81.Се1Тги81е6Т1те. Этот вызов не берет никаких аргументов и возвращает, в вершину стека, доверенное время и значение одного или нескольких флагов. В одном варианте осуществления, доверенное время это текущее значение доверенных часов (если система включает в себя такие доверенные часы), или отрицательный код ошибки, если доверенное время недоступно. В одном варианте осуществления, значение доверенного времени выражается 32-битовым знаковым целым, равным числу минут, прошедших с 00:00:00 1 января 1970 г. согласно ИТС, или отрицательным кодом ошибки. В одном варианте осуществления, представляют собой набор битовых флагов, которые дополнительно задают текущее состояние доверенных часов. В одном варианте осуществления, в случае возникновения ошибки (например, значение Тш81е6Т1те равно отрицательному коду ошибки) возвращается значение флагов, равное 0.
В одном варианте осуществления, задается следующий флаг:
| Битовый индекс (0 это ЬЗВ) | Имя | Описание | |
| 0 | Т1МЕ_13_Е5Т1МАТЕ | Известно, что значение Тгив1:ес1Т1те не является самым точным его значением, и поэтому должно рассматриваться как оценка. |
Этот системный вызов имеет смысл в системах, где реализованы доверенные часы, которые можно синхронизировать с доверенным источником времени, и поддерживается монотонный счетчик времени. Не гарантируется, что значение доверенного времени всегда будет точным, но в одном варианте осуществления требуется наличие следующих свойств:
значение доверенного времени выражается как значение времени ИТС (доверенное время не является местным временем, поскольку текущее местоположение обычно нельзя точно определить);
доверенное время никогда не идет назад;
доверенные часы идут не быстрее реального времени.
Поэтому, в этом иллюстративном варианте осуществления, значение ТпгЛебТппе находится между значением последнего синхронизированного времени (синхронизированного с доверенным источником времени) и текущим реальным временем. Если система способна определить, что ее доверенные часы действовали и обновлялись постоянно и нормально без перерыва с момента последней синхронизации с доверенным источником времени, она может определить, что значение ТгийебПте является не оценочным, а точным значением, и задать флаг Т1МЕ_18_Е8Т1МАТЕ равным 0.
В одном варианте осуществления, если доверенные часы обнаруживают, что наступило условие аппаратного или программного сбоя, и они не могут возвратить даже оценку доверенного времени, возвращается код ошибки, и значение возвращаемых флагов задается равным 0.
8у51ет.Но51.Се1ОЬ)ес1: Этот системный вызов является общим интерфейсом, который позволяет программе обращаться к объектам, обеспеченным хостом виртуальной машины. Вызов 8у§1ет.Но51.СеЮЬ)ес1 берет следующие аргументы (перечисленные от вершины стека вниз): Рагеп!, Ыате, Ее1игпВиГГег и Ее1игпВиГГег8|/е. Где РагепГ это 32-битовый описатель родительского контейнера; Ыате это адрес строки, оканчивающейся символом конца строки, содержащей путь к запрашиваемому объекту относительно родительского контейнера; КеШгпБнГГег это адрес буфера памяти, где должно храниться значение объекта; и ВеШтВиПсгЕихе это 32-битовое целое, указывающее размер в байтах буфера памяти, где должно храниться значение объекта.
Вызов 8у81ет.Но81.Се1ОЬ]ес1 создает следующие выходы (перечисленные от вершины стека вниз): ТуреШ, δί/е. ТуреИ это ίά типа объекта или отрицательный код ошибки, если вызов не удается. Если запрашиваемый объект не существует, возвращается ошибка в виде ЕККОК_ЫО_8иСН_1ТЕМ. Если буфер, предоставленный для возвращаемого значения, слишком мал, возвращается ошибка в виде ЕККОК_ГЫ8иЕЕ1С1ЕМТ_8РАСЕ. Если часть дерева объектов, к которой происходит обращение, имеет управление доступом, и вызывающая программа не имеет разрешения на доступ к объекту, возвращается ЕККОК_РЕКМ1881ОМ_ПЕМ1ЕП. Также могут возвращаться и другие коды ошибки. δί/е это 32битовое целое, указывающее размер в байтах данных, возвращаемых в буфер, предоставленный вызывающей сущностью, или необходимый размер, если вызывающая сущность обеспечила слишком малый буфер.
В одном варианте осуществления существует четыре типа объектов хоста: строки, целые числа, массивы байтов и контейнеры.
- 51 012918
| Тип объекта | Имя Ш типа | Значение Ιά типа |
| Контейнер | ΟΒσΕΟΓ_ΤΥΡΕ_ΟΟΝΤΑΙΝΕΚ | 0 |
| Целое | ОВЦЕСТ_ТУРЕ_1ИТЕСЕК | 1 |
| Строка | 0ВЦЕСТ_ТУ?Е_ЗТКШС | 2 |
| Массив байтов | ОВЦЕСТ_ТУРЕ_ВУТЕ_АККАУ | 3 |
В одном варианте осуществления значение объекта «массив байтов» представляет собой массив 8битовых байтов, значение объекта «строка» представляет собой строку символов, оканчивающуюся символом конца строки, закодированную в ИТЕ-8, и значение объекта «целое число» представляет собой 32битовое знаковое целочисленное значение. Контейнеры представляют собой контейнеры общего вида, которые содержат последовательность из любого количества объектов любой комбинации типов. Объекты, содержащиеся в контейнере, называются детьми этого контейнера. Значение контейнера представляет собой 32-бтовый описатель контейнера, уникальный в данном экземпляре νΜ. В одном варианте осуществления, корневой контейнер '/' имеет фиксированное значение описателя 0.
В одном варианте осуществления пространство имен для объектов хоста имеет иерархическую структуру, где имя дочернего объекта контейнера строится путем присоединения имени дочернего объекта к имени родительского контейнера, каковые имена разделены символом '/'. Объекты «строка» и «целое число» не имеют детей. Например, если контейнер назван 7№йс/ЛипЬи1с5' и имеет дочернюю строку под именем 'Туре', то 7№йс/АипЬи1с5/Турс' относится к дочерней строке.
Корнем пространства имен является '/'. Все абсолютные имена начинаются с '/'. Имена, которые не начинаются с '/', являются относительными именами. Относительные имена относятся к родительскому контейнеру. Например, имя 'А41пЬи4с8/Турс', относительно родителя 7№йс', это объект с абсолютным именем 7№0с/АипЬи1с5/Турс'.
В одном варианте осуществления, объекты «контейнер» также могут иметь реальные и виртуальные дочерние объекты, к которым можно обращаться с использованием виртуальных имен. Виртуальные имена это имена, которые не присоединены объектам хоста, но, по соглашению, идентифицируют либо безымянные дочерние объекты, дочерние объекты с другим именем, либо виртуальные дочерние объекты (дочерние объекты, которые не являются реальными детьми контейнера, но динамически создаются по запросу).
В одном варианте осуществления, для объектов, следующие виртуальные имена заданы как имена виртуальных дочерних объектов:
| Виртуальное имя | Описание | |
| Эйате | Виртуальный объект «строка»: имя | |
| объекта. | ||
| Если объект не имеет | имени, | |
| значение является пустой строкой. | ||
| Заметим, что безымянные | объекты | |
| доступны только через | @<п> | |
| виртуальное имя | объекта | |
| «контейнер» (см. ниже) | ||
| @3ϊζβ | Виртуальный объект «целое | число». |
| Целочисленное значение | равно | |
| размеру в байтах, необходимому для | ||
| сохранения этого объекта. Для | ||
| целых чисел, это значение равно 4; | ||
| для строк, это количество | байтов, | |
| необходимое для сохранения | строки | |
| в кодировке иТЕ-8 плюс | пустой | |
| байт-знак конца строки | . Для | |
| массивов байтов, это количество | ||
| байтов в массиве | ||
| @Туре | Виртуальный объект «целое | число». |
| Целочисленное значение равно Туре | ||
| 1с1 объекта |
- 52 012918
Для контейнеров, следующие виртуальные имена заданы как имена виртуальных дочерних объектов в одном варианте осуществления:
| Виртуальное имя | Описание | |
| Виртуальный индекс | @<п> | Виртуальный объект: <п>-й объект в контейнере. Первый объект в контейнере имеет индекс 0. <л> выражается десятеричным числом. Пример: если 'АМ^гхЬиЪез' это контейнер, который содержит 5 дочерних объектов, 'А£1:г1Ьц£е5/@4' это 5-й дочерний объект контейнера. |
| Виртуальный размер | ΘΞίζθ | Виртуальный объект «целое число». Целочисленное значение равно количеству объектов в контейнере. |
Примеры. В нижеследующей таблице приведен пример иерархии объектов Ной:
Имя Значение Дети
| Νο<1ε 1 | Имя | Значение Дети | |||
| Туре | ‘Όενίοβ” | ||||
| Имя | Значение | Дети | |||
| А11г1Ьи1еь | 2 | Имя Со1ог | Значение “Кед” | Дети | |
| Имя 5ίζε | Значение 78 | Дети | |||
| Имя Эоташ | Значение “ТорЬеуе]” | Дети |
В этом примере, вызов 8уйе1п.Ной.Се1ОЬ)ес1 (рагеп!=0, пате=№бе) возвращает ΙΌ типа 0 (т.е. контейнер) и приводит к записи значения описателя 1 в буфер, предоставленный вызывающей сущностью. Размер значения равен 4 байтам.
Вызов 8уйет.Ной.Се1ОЬ)ес1 (рагеп!=0, пате-^обе/АйпЬЩек/Потат) возвращает ΙΌ типа 2 (т.е. строку) и приводит к записи строки ТорЬеуе1 в буфер, предоставленный вызывающей сущностью. Размер значения равен 9 байтам.
Вызов 8уйе1п.Ной.Се1ОЬ)ес1 (рагеШ=1, иате=Абг1Ьи1:е8/@1) возвращает ΙΌ типа 1 (т.е. целое) и приводит к записи целого числа 78 в буфер, предоставленный вызывающей сущностью. Размер значения равен 4 байтам.
Вызов 8уйет. Ной.Се1ОЬ)ес1 (рагеп1=0, пате=Оое5№1Ех1й) возвращает код ошибки ЕКΚΟΚ_ΝΟ_8υ№_ΠΈΜ.
8уйе1п.Ной.8е1ОЬ|ес1. Этот системный вызов является общим интерфейсом, который позволяет программе создавать, записывать и уничтожать объекты, обеспеченные хостом виртуальной машины. Описание имен и типов объектов такое же, как для вышеописанного вызова 8уйе1п.Ной.Се1ОЬ)ес1. Заметим, что объекты хоста поддерживают возможность своей записи или уничтожения, и не все контейнеры поддерживают создание дочерних объектов. Когда производится вызов 8е1ОЬ)ес1 объекта, который не поддерживает операцию, возвращается ЕККΟК_РЕКΜI88IΟN_^ΈNIΈ^.
Системный вызов 8уМе1п.Ной.8е1ОЬ)ес1 берет в качестве аргументов следующие параметры, перечисленные от вершины стека вниз:
Вершина стека
- 53 012918
РагеШ: 32-битовый описатель родительского контейнера.
Бате: адрес строки, оканчивающейся символом конца строки, содержащей путь к объекту относительно родительского контейнера.
ОЬ)ес1Л66гекк: адрес буфера памяти, где хранится значение объекта. Если адрес равен 0, вызов интерпретируется как запрос на уничтожение объекта. Данные по адресу зависят от типа объекта.
ОЬ)ес1 Туре: ΙΌ типа объекта.
ОЬ)ес18|/е: 32-битовое целое, указывающее размер в байтах буфера памяти, где хранится значение объекта. В рассматриваемом иллюстративном варианте осуществления, размер задан равным 4 для объектов «целое число» и размеру буфера памяти, с учетом пустого символа конца строки, для объектов «строка». Для объектов «массив байтов», размер равен количеству байтов в массиве.
Системный вызов 8ук1ет.Нок1.8е1ОЬ)ес1 возвращает КекиИСобе в вершину стека в качестве выхода. КекиИСобе равен 0, если вызов успешен, и равен отрицательному коду ошибки, если вызов неудачен. Если вызов является запросом на уничтожение объекта, и запрашиваемый объект не существует, или вызов является запросом на создание или запись объекта, и родитель объекта не существует, возвращается код ошибки в виде ЕККОК_ЫО_8иСН_1ТЕМ. Если часть дерева объектов, к которой происходит обращение, имеет управление доступом, и вызывающая программа не имеет разрешения на доступ к объекту, возвращается ЕККОК_РЕКМ1881ОМ_ПЕЫ1ЕП. Также могут возвращаться и другие коды ошибки.
Существует особый случай, когда объект ссылается на контейнер, и ОЬ)ес1Л66гекк не равен 0. В этом случае параметр ОЬ)ес18|/е задается равным 0, и значение ОЬ)ес1Л66гекк игнорируется. Если контейнер уже существует, ничего не происходит, и возвращается КекиИСобе равный 8ИССЕ88. Если контейнер не существует, и родитель контейнера является записываемым, создается пустой контейнер.
Ос1орик.Еткк.1кХо6еКеас11аЬ1е. Этот системный вызов используется программами управления для проверки, доступен ли данный узел от узла, связанного с сущностью, вмещающей этот экземпляр виртуальной машины. Вызов берет в качестве аргумента ЫобеИ из вершины стека, где ЫобеИ это строка, оканчивающаяся символом конца строки, содержащая ΙΌ конечного узла, подлежащего тестированию на доступность. В качестве выхода, вызов возвращает КекиЕСобе и 8!а!икВ1оскРош!ег в вершину стека. КекиИСобе это целочисленное значение, равное 0, если узел доступен, или отрицательный код ошибки, если нет. 8!а!икВ1оскРош!ег это адрес стандартного Ех1еп6е681а1икВ1оск. или 0, если не возвращается ни одного блока состояний.
8ук1ет.Нокк8ра\упУт. Этот системный вызов используется программами управления для запроса на создание нового экземпляра виртуальной машины и на загрузку нового кодового модуля. В одном варианте осуществления, хост вновь созданной виртуальной машины предъявляет те же объекты хоста, которые предъявлялись вызывающей сущности, за исключением того, что объект хоста /ОсЮрик/Кип!1те/Рагеп!/И задан равным идентификатору вызывающей сущности. В одном варианте осуществления, этот объект хоста является контейнером. Детьми этого контейнера являются объекты типа строка, каждый из которых имеет значение, представляющее имя. В одном варианте осуществления, семантика и конкретные детали этих имен указаны в спецификации хоста виртуальной машины.
В одном варианте осуществления, когда виртуальная машина, которая выполняет код для вызывающей сущности прекращает существование, любая порожденная виртуальная машина, которая не была в явном виде освобождена путем вызова 8ук!ет.Нок!.Ке1еакеУт, автоматически освобождается системой, как при вызове 8ук1ет.Нок1.Ке1еакеУт.
Вызов 8ук1ет.Нок1.8ра\упУт берет в качестве аргумента Мо6и1еИ из вершины стека. Мо6и1еИ идентифицирует кодовый модуль, подлежащий загрузке в новый экземпляр виртуальной машины. В одном варианте осуществления, спецификация хоста виртуальной машины описывает механизм, позволяющий находить фактический кодовый модуль, соответствующий этому ΙΌ модуля.
Вызов 8ук1ет.Нок1.8ра\упУт возвращает КекиИСобе и УтНап61е в вершину стека. КекиИСобе это целочисленное значение, равное 0, если вызов успешен, и отрицательному коду ошибки, если он неудачен. УтНап61е это целочисленное значение, идентифицирующее экземпляр виртуальной машины, который был создан. В случае неудачного вызова, этот описатель задается равным 0. В одном варианте осуществления, гарантируется лишь, что этот описатель будет уникальным в виртуальной машине, в которой делается этот вызов.
8ук!ет.Нок!.Са11Ут. Этот системный вызов используется программами управления для вызова процедур, реализованных в кодовых модулях, загруженных в экземпляры виртуальной машины, созданные с использованием системного вызова 8ук1ет.Нок1.8ра\упУт. Этот системный вызов берет следующие аргументы, начиная с вершины стека.
Вершина стека:
УтНапЛе
ΕηΙτγΡοίηί
Рагате1егВ1оскД<1с1ге58
Рагате!егВ1оск81ге
Г<е1итВиЙ’егЛс1с1гез5
- 54 012918
К.е1итВийег312е
УтНапб1е: целочисленное значение, представляющее описатель виртуальной машины, созданной путем вызова 8ук1ет.Нок1.8ра\\'пУт.
ΕπίΓνΡοίπΙ: адрес строки, оканчивающейся символом конца строки, которая задает имя точки входа в вызов. Это имя должно совпадать с именем одной из точек входа в таблице экспорта кодового модуля, загруженного в экземпляр виртуальной машины, который соответствует параметру УтНапб1е.
Рагате1егВ1оскАббгекк: адрес блока памяти, который содержит данные, подлежащие передаче вызываемой сущности. Если вызываемой сущности не передаются никакие параметры, этот адрес задается равным 0.
Рагаше1егВ1оск8|/е: размер в байтах блока памяти по адресу Рагаше!егВ1оскЛббге88 или 0, если Рагаше!егВ1оскЛббге88 равен 0.
Ке1игпВиГГегАббгекк: адрес буфера памяти, где вызывающая сущность может принимать данные от вызываемой сущности. Если вызывающая сущность не ждет никаких данных от вызываемой сущности, этот адрес задается равным 0.
КеШгпВиГГегЕбхе: размер в байтах буфера памяти по адресу Ке!игпВиЕГегАббгекк или 0, если КеШгпВиЕГегАббгекк равен 0.
Вызов 8ук1ет.Нок1.Са11Ут возвращает следующий выход в вершину стека:
Вершина стека:
8уз1етВ.езикСобе
СаПееКезикСоке
Ке1итВ1оск8|ге
8ук1етКеки11Собе: целочисленное значение, равное 0, если вызов увенчался успехом, или отрицательному коду ошибки в случае неудачи. Это значение определяется системой, а не вызываемой сущностью. Успех указывает лишь, что система смогла успешно найти процедуру для вызова, выполнить процедуру и получить возвращаемое значение от процедуры. Возвращаемое значение от самой роцедуры возвращается в виде значения Са11ееКекиЙСобе.
Са11ееКекиЙСобе: целочисленное значение, возвращаемое вызываемой сущностью.
КеШгпВ1оск8|/е: размер в байтах данных, возвращаемых в буфер, предоставленный вызывающей сущностью, или необходимый размер, если вызывающая сущность обеспечила слишком малый буфер. Если вызываемая сущность не возвращает никаких данных, значени равно 0.
В рассматриваемом иллюстративном варианте осуществления, вызываемая процедура отвечает следующим соглашениям по интерфейсу: при вызове процедуры, вершина стека содержит значение Рагате1егВ1оск8|/е. обеспеченное вызывающей сущностью, указывающее размер блока параметра, следующего после байтов данных Рагате1егВ1оск8|/е. Если размер не кратен 4, данные в стеке дополняются нулями, чтобы указатель стека оставался кратным 4. По возвращении, вызываемая процедура помещает в стек следующие возвращаемые значения:
Вершина стека:
КезикСобе
КсШтВ 1оскАб бгезз
Ке(итВ 1оск81ге
Ке1игпВ1оскАббгекк: адрес блока памяти, который содержит данные, возвращаемые вызывающей сущности. Если никаких данных не возвращается, этот адрес задается равным 0.
КеШгпВ1оск8|/е: размер в байтах блока памяти по адресу Ке!игпВ1оскАббгекк или 0, если КеШгпВ1оскАббгекк равен 0.
8ук1ет.Нок1.Ке1еакеУт. Этот системный вызов используется программами управления для освобождения виртуальной машины, порожденной предыдущим вызовом 8ук1ет.Нок1.8ра\упУт. Любые виртуальные машины, порожденные отпущенной виртуальной машиной, освобождаются, и т.д., рекурсивно. Вызов 8ук1ет.Нок1.Ке1еакеУт берет в качестве аргумента УтНапб1е из вершины стека, причем УтНапб1е представляет описатель виртуальной машины, созданной путем вызова 8ук1ет.Нок1.8ра\упУт. Вызов 8ук1ет.Нок1.Ке1еакеУт возвращает в вершину стека КекиЙСобе в качестве выхода. КекиЙСобе это целочисленное значение, равное 0, если вызов увенчался успехом, или отрицательному коду ошибки в случае неудачи.
8.4.3. Стандартные структуры данных.
Ниже описаны стандартные структуры данных, используемые некоторыми стандартными системными вызовами.
8.4.3.1. Стандартные параметры.
- 55 012918
Рагате1егВ1оск:
Имя
Тип
Иате
ИатеВ1оск
Уа1ие _
Уа1иеВ1оск
Каше: имя параметра.
Уа1ие: значение параметра Ех1еийейРагате1егВ1оск:
Р1ад§: вектор логических флагов.
Ратате1ет: блок параметра содержащий имя и значение. №ипеВ1оск:
8|/е: 32-битовое беззнаковое целое, равное размеру в байтах следующего за ним поля сйагас1ег8. Если это значение равно 0, поле сйатас1ег8 остается пустым (т.е. после него ничего нет).
С11агас1ег5: строка ИТР-8, оканчивающая символом конца строки.
Уа1иеВ1оск:
32-битовое целое
32-битовое целое байтов
Массив
8-битовых
Туре: 32-битовый идентификатор типа. В одном варианте осуществления, заданы следующие типы:
Идентификатор Имя типа
Описание
ТпГедег
32-битовое целочисленное значение, закодированное в виде четырех
8-битовых байтов обратном порядке следования байтов.
одном варианте осуществления значение считается знаковым, если не указано обратное.
Кеа!
32-битовое значение с плавающей точкой, закодированное согласно ΙΕΕΕ-754 в обратном порядке следования байтов
Строка о кан чив ающая симв ол ом конца строки
- 56 012918
представляющее минут.
прошедших осуществления.
указано которого
Структура оканчивающуюся символом конца строки.
который ссылку нужно снять, получить данные.
кодированный собой массив 8-битовых байтов одном варианте собой строку δίζβ: 32-битовое беззнаковое целое, равное размеру в байтах следующего за ним поля ба!а. Если это значение равно 0, поле данных остается пустым (т.е. после поля δίζβ в Уа1иеВ1оск ничего нет).
Эа1а: массив 8-битовых байтов, представляющий значение. Фактические байты зависят от кодировки данных, указанной в поле 1уре.
Уа1иеЕ18®1оск:
| Имя | Тип |
| Уа1иеСоип( | 32-битовое целое |
| Уа1ие0 | Уа1иеВ1оск |
| Уа1ие1 | Уа1иеВ1оск |
Уа1иеСоип1: 32-битовое беззнаковое целое, равное количеству следующих после него структур Уа1иеВ1оск. Если это значение равно 0, структур Уа1иеВ1оск нет.
Уа1ие0, Уа1ие1, ...: последовательность из нуля или более структур Уа1иеВ1оск.
8.4.3.2. Стандартная структура Ех1епбеб81а1и5.
Стандартная структура Ех1епбеб81а1и5В1оск это структура данных, обычно используемая для переноса расширенной информации в качестве состояния возврата из вызова процедуры или системного вызова. Это общего вида структура данных, которую можно использовать в различных контекстах, причем ее поля могут принимать разнообразные значения. В одном варианте осуществления, Ех1епбеб81а1и5В1оск задается следующим образом.
Ех1епйей81а1и5В1оск:
- 57 012918
| Имя | Тип |
| С1оЬа1Г1а&8 | 32-битовое битовое поле |
| Са1е§огу | 32-битовое целое |
| 8иЬСа1е§огу | 32-битовое целое |
| Ьоса1Г1а£8 | 32-битовое битовое поле |
| СасЬеОигайоп | СасЬеОига11опВ1оск |
| Рагаше1ег8 | Уа1ие1.151В1оск |
С1оЬа1Е1адк: логические флаги, имеющие одну и ту же семантику вне зависимости от поля Са1едогу. Позиция и смысл флагов определяются профилями, которые используют стандартные структуры данных Ех(епбеб81а1икВ1оск.
Са1едогу: Уникальный целочисленный идентификатор категории, к которой принадлежит это состояние. Значения идентификатора категории определяются профилями, которые используют стандартные структуры данных Ех(епбеб81а1икВ1оск.
8иЬСа1едогу: Целочисленный идентификатор (уникальный в рамках категории) подкатегории, которая дополнительно классифицирует тип состояния, описанного этим блоком.
ЬосаИадк: Логические флаги, семантика которых локальна по отношению к категории и подкатегории этого блока состояний. Позиция и смысл флагов определяются профилями, которые задают и ис пользуют семантику категории.
СасНеЭигаНоп: Указывает продолжительность времени, в течение которого это состояние может кэшироваться (т.е. остается действительным). См. ниже определение типа СасЬеПига1юпВ1оск, чтобы понять, как задается фактическое значение продолжительности времени.
Рагате(егк: список из нуля или более структур Уа1иеВ1оск. Каждая структура Уа1иеВ1оск содержит параметр, кодированный как значение типа Рагате!ег или Ех(епбебРагате1ег. Каждый параметр привязывает имя к типизированному значению и используется для кодирования гибких изменяемых данных, которые описывают блок состояний более подробно, чем просто категория, подкатегория, время жизни кэша и флаги.
СасНеЭига11опВ1оск:
| Имя | Тип |
| Туре | 32-битовое целое |
| Уа1ие | 32-битовое целое |
Туре: Целочисленный идентификатор типа значения.
одном варианте осуществления, заданы следующие типы:
| Тип | Описание | ||
| 0 | Значение | представляет | собой |
| 32-битовое | беззнаковое | целое, | |
| которое | представляет | число | |
| секунд от | текущего времени. | ||
| Значение | 0 означает, | что | |
| состояние | вовсе | нельзя | |
| кэшировать | и потому | можно | |
| использовать только один раз. | |||
| Особое значение ОхГГГГГГГГ | |||
| инт ерпре тируе тся | как | ||
| бесконечная длительность | |||
| (т.е., | состояние | можно | |
| кэшировать | сколь | угодно | |
| долго). | |||
| 1 | Значение | представляет | собой |
| 32-битовое | беззнаковое | целое, | |
| которое | представляет | ||
| абсолютное | местное | время, | |
| выраженное | числом | минут, | |
| прошедших | с 00:00:00 1 | января | |
| 1970 г. | В одном варианте | ||
| осуществления, старший | бит | ||
| должен быть равен 0. |
- 58 012918
Vа1ие: 32-битовое целое, смысл которого зависит от поля Туре.
8.4.4. Стандартные коды результата.
Стандартные коды результата используются в различных АР1. Для использования в более специальных АР1 можно задать другие коды результата.
| Значение | Имя | Описание |
| 0 | зоссезз | Успех |
| -1 | гмъикЕ | Неудача по неустановленной причине |
| -2 | ΕΚΚΟΚ_ΙΝΤΕΚΝΑΕ | Произошла внутренняя ошибка (связанная с реализацией) |
| -3 | ЕКНОК_1ЫУАЫО_РАКАМЕТЕК | Параметр имеет недействительное значение |
| -4 | ΕΗ80Κ__0υΤ_0Γ_ΜΕΜ0ΚΥ | Недостаточно памяти для успешного завершения |
| -5 | Еякок_оит_ог_аЕЗоиксЕЗ | Недостаточно ресурсов для успешного завершения |
| -6 | ЕРКОН_ЫО_ЗиСН_1ТЕМ | Запрошенный элемент не существует или не найден |
| -7 | ЕЯКОК 1МЗиГГ1С1ЕМТ ЗРАСЕ | Вызывающая сущность выделила недостаточно памяти (обычно используется, когда буфер возврата слишком мал) |
| -8 | ΕΚΡΟΗ ΡΕΗΜΙ33ΙΟΝ ΟΕΝΙΕϋ | Разрешение на выполнение вызова отменено вызывающей сущностью. |
| -9 | ΕΗΚΟΡ_ΗυΝΤΙΜΕ_ΕΧΟΕΡΤΙΟΝ | Возникла ошибка при выполнении байт-кода |
| -10 | ЕКЕОК_1К7АЫО_ЕОКМАТ | Ошибка, обусловленная недействительным форматом данных (например, недействительные данные в кодовом модуле) |
8.5. Синтаксис ассемблера.
В этом разделе описан иллюстративный синтаксис для использования при компилировании программы в формат байт-кода описанный здесь в другом месте. Очевидно, что это лишь один пример возможного синтаксиса, и что можно использовать любой подходящий синтаксис. Как указано выше, следует также понимать, что представленный здесь формат байт-кода также является иллюстративным, и что описанные здесь системы и способы можно использовать с любым другим пригодным форматом байткода или другим форматом кода.
Ассемблер считывает исходные файлы, содержащие код, данные и команды обработки, и создает двоичные кодовые модули, которые могут загружаться виртуальной машиной управления. В одном иллюстративном варианте осуществления, ассемблер обрабатывает исходный файл последовательно, строку за строкой. Строки могут содержать нуль или более символов, после которых следует разделитель строк. Каждая строка может представлять собой: пустую строку (только пробел), директиву сегмента, директиву данных, директиву ассемблера, команду кода, метку или директиву экспорта. Кроме того, каждая строка может заканчиваться комментарием, который начинается с символа и продолжается до конца строки.
Данные и команды, считанные из исходных файлов, имеют неявный сегмент назначения (т.е., куда они попадут, будучи загружены νΜ). В любой момент в ходе процесса анализа, ассемблер будет иметь текущий сегмент, который является неявным сегментом назначения для данных и команд. Текущий сегмент можно менять с использованием директив сегмента.
8.5.1. Директива сегмента.
Директивы сегмента изменяют текущий сегмент анализатора. В одном варианте осуществления поддерживаются директивы сегмента .собе и .ба(а. Сегмент .собе содержит команды байт-кода, и сегмент .ба(а содержит глобальные переменные.
- 59 012918
8.5.2. Директивы данных.
Директивы данных указывают данные (например, целые числа и строки), которые будут загружены в сегмент данных виртуальной машины. В одном варианте осуществления поддерживаются следующие директивы данных:
.Чппд <5оте сйаг8> - Задает строку символов. В одном варианте осуществления ассемблер добавляет октет со значением 0 в конец строки.
.Ьу!е <уа1ие> - Задает 8-битовое значение. <уа1ие> может выражаться десятеричным числом или шестнадцатеричным числом (предваряемым 0х).
8.5.3. Директивы ассемблера.
В одном варианте осуществления поддерживается директива ассемблера .еди <кутЬо1>, <уа1ие>, которая задает символ <кутЬо1> равным значению <уа1ие>. Символы обычно используются в качестве операндов или кодовых команд.
8.5.4. ЬаЬек.
Метки это символы, указывающие те или иные позиции в сегментах. Метки, указывающие на команды в сегменте кода, обычно используются для команд перехода/ветвления. Метки, указывающие на данные в сегменте данных, обычно используются для ссылки на переменные. В одном варианте осуществления используется следующий синтаксис метки: <ЬАВЕЬ>:
Заметим, что после ничего не стоит, кроме необязательного комментария. Метка указывает позицию следующего(ей) элемента данных или команды. В одном варианте осуществления разрешено иметь более одной метки, указывающей один и тот же адрес.
8.5.5. Директивы экспорта.
Директивы экспорта используются для создания элементов в секции ехрой кодового модуля, создаваемого ассемблером. Каждый элемент в секции экспорта представляет собой пару (имя, адрес). В рассматриваемом иллюстративном варианте осуществления в секции экспорта можно указывать только адреса в сегменте кода.
Синтаксис директивы экспорта: .ехрой <1аЬе1>, которая экспортирует адрес, указанный посредством <1аЬе1>, под именем <1аЬе1>.
8.5.6. Кодовые команды.
При компилировании данных, предназначенных для сегмента кода, ассемблер считывает команды, которые отображаются, прямо или косвенно, в байт-коды. В иллюстративном наборе команд, показанном выше, большинство байт-кодов виртуальной машины не имеют прямых операндов и выглядят как простой мнемокод в одной строке. Чтобы сделать синтаксис ассемблера более читаемым, некоторые команды принимают псевдооперанды, которые выглядят так, как если бы они были операндами байт-кода, но в действительности таковыми не являются; в этом случае, ассемблер генерирует одну или несколько команд байт-кода для создания такого же эффекта, как если бы команда имела прямой операнд. Например, команды ветвления используют псевдооперанды.
8.5.6.1. Операнды ветвления.
Команды ветвления можно задавать дословно (безо всяких операндов) или с необязательным операндом, который ассемблер будет преобразовывать в соответствующую последовательность байт-кодов. Необязательный операнд является целочисленной константой или символом. Когда операнд является символом, ассемблер вычисляет правильное целочисленное относительное смещение, чтобы ветвление заканчивалось по адресу, соответствующему символу.
8.5.6.2. Операнды Рикк.
В одном варианте осуществления команда ΡυδΗ всегда берет один операнд. Операнд может представлять собой целочисленную константу, символ или префикс @, после которого сразу следует имя метки. Когда операнд является символом, проталкиваемое значение является непосредственным значением этого символа, независимо от того, является ли символ меткой или символом .еди (значение не увеличивается на величину смещения сегмента). Когда операнд является именем метки, предваряемым @, проталкиваемое значение зависит от того, на что указывает метка. Значение, проталкиваемое в стек, является абсолютным адресом, представленным меткой (т.е. суммой локального значения метки и смещения сегмента).
8.5.7. Примеры.
; константы •еяи 5ОМЕСОЙЗТ, 7 ; которые следуют, идут в сегмент данных
- 60 012918 • даСа
ΫΑΚ1:
. ЬуСе 8
УАВ2:
.з£г1пд Ъе11о\0
| УАКЗ: ,1опд УАК4 : | 0ХЕЕГСОА07 |
| . 1опд | 0 |
; которые следуют, идут сегмент кода . соде
ТОО:
Ρ03Η
ΑϋΡ
КЕТ
ВАН:
ризн ризн @гоо ί3Β ризн ризн ризн ризн
РЕЕК
ЗОМЕСОИЗТ ; 6УАК1 УАВ1 @УАЙЗ ί
ризн @УАК4 ; протолкнуть адрес метки ГОС перейти к коду по метке ЕОО протолкнуть протолкнуть протолкнуть протолкнуть протолкнуть
РОКЕ ризн
УАК 2 значение 7 адрес УАК1 смещение νΑΚΙ в сегменте данных адрес νΑΚ3 значение УАВЗ ) протолкнуть адрес УАК4 сохранить значение на вершине стека в νΑΚ4 протолкнуть адрес строки Ье11о
8.5.8. Синтаксис командной строки.
В одном варианте осуществления, ассемблер представляет собой инструмент командной строки, который можно вызывать с помощью следующего синтаксиса:
Рк!АккетЬ1ег[опции]<три!_Г11е_ра!й><ои!ри!_Г11е_ра!й>, где [опции] могут быть: -ск ίηΐ, -άκ ίηΐ, хт1 ίά или -Ь, где -ск ίηΐ. это Сегмент кода ΛάάΐΌΚΚ Уа1ие (ЧеГаи11 = 8), ''-άκ ίηΐ представляет собой значение адреса сегмента данных (по умолчанию = 4), -хт1 ίά используется для вывода объекта управления в виде файла ΧΜΌ с указанным ΙΌ, и ''-Ь используется для отображения информации помощи.
9. Объекты управления.
В этом разделе описаны иллюстративные варианты осуществления объектов управления. Объекты управления можно использовать для представления правил, которые регламентируют доступ к контенту путем разрешения или запрещения использования объектов Сои!еи!Кеук, которыми они управляют. Их также можно использовать для представления ограничений по действительности объекта «связь», в который они внедрены. Их также можно использовать в качестве самостоятельных программных контейнеров, которые выполняются от имени другой сущности, например, в агентах или делегатах. В одном варианте осуществления объекты управления содержат метаданные и программы в виде байт-кода, которые реализуют конкретный протокол взаимодействия. Протокол управления имеет целью задавать взаимодействие между механизмом ΌΒΜ и программой управления или между приложением хоста и программой управления через механизм ΌΚΜ. В этом разделе также описаны иллюстративные действия, которые приложение может осуществлять на контенте, параметры действия, которые нужно передавать программе управления, и показано, как программа управления кодирует состояние возврата, указывающее, что запрошенное действие может или не может быть выполнено, а также параметры, которые могут дополнительно описывать состояние возврата.
В этом разделе используются следующие аббревиатуры и акронимы:
Е8В: расширенный блок состояний;
Ь8В: младший бит;
Ву!е: 8-битовое значение или октет;
Байт-код: поток байтов, которые кодируют исполнимые команды и их операнды.
9.1. Программы управления.
В одном варианте осуществления объект управления содержит программу управления. Программа управления включает в себя кодовый модуль, содержащий байт-код, который может выполнять виртуальная машина, и список именованных процедур (например, элементов таблицы экспорта).
В одном варианте осуществления набор процедур, которые представляют правила, регламентирующие осуществление определенной операции (например воспроизведение) на элементе контента, называется 'управляющий элемент действия'. Набор процедур, которые представляют ограничения по действительности на объекте «связь», называется ограничение по связи. Набор процедур, предназначенных для выполнения от имени удаленной сущности (например, в течение сеанса протокола, когда механизм ΌΒΜ выполняется на другом хосте), называется агент. Набор процедур, предназначенных для выполнения от имени другого управляющего элемента (например, когда программа управления использует системный вызов 8ук!ет.Нок!.Са11Ут), называется делегат.
9.1.1. Интерфейс к программам управления.
- 61 012918
В одном варианте осуществления программы управления выполняются виртуальной машиной, выполняющейся в среде хоста. Среду хоста можно реализовать любым подходящим способом; однако, для простоты объяснения и в целях иллюстрации, в нижеследующем рассмотрении предполагается, что реализацию среды хоста виртуальной машины можно логически разделить на две части: приложение хоста и механизм ΌΚΜ. Однако очевидно, что другие варианты осуществления могут иметь другое логическое разделение функций, которое может быть эквивалентным вышеописанной логической структуре.
Как и на фиг. 29, в предпочтительных вариантах осуществления механизм ΌΚΜ 2908 является логическим интерфейсом между приложением хоста 2900 и программами управления 2906. Приложение хоста 2900 делает логические запросы механизму 2908, например, запрашивая доступ к ключу контента с определенной целью (например, для воспроизведения или представления потока контента). В одном варианте осуществления механизм 2908 гарантирует, что описанный ниже протокол взаимодействия реализован правильно, например, гарантируя, что любые гарантии, касающиеся инициализации программы управления, последовательности вызовов и других деталей взаимодействия соблюдаются.
Когда приложение хоста 2900 запрашивает использование ключей контента для набора ГО контента, механизм ΌΚΜ 2908 определяет, какой объект Соп1го1 использовать. Объекты Рго1ес1ог позволяют механизму определять, к каким объектам СоШеЩКеу нужно обращаться на предмет запрошенных ГО контента. Затем механизм находит объект Соп!го11ег, который ссылается на эти объекты СоШеЩКеу. В одном варианте осуществления, объект Соп!го11ег может ссылаться на более чем один объект СоШеЩКеу.
Это позволяет управлять несколькими объектами СоЩеШКеу посредством одного и того же объекта Соп1го1. Когда приложение хоста запрашивает доступ к ключу контента путем вызова действия, оно может запросить множественные ГО контента как группу, в той мере, в какой один и тот же объект Соп1го11ег ссылается на соответствующие им объекты СоЩеШКеу. В одном варианте осуществления, запрос на доступ к группе ключей контента, на которые ссылаются более одного объекта «контроллер», не разрешен.
В одном варианте осуществления механизм ΌΚΜ следует соглашению по отображению действий в имена процедур. Например, в одном варианте осуществления для каждой из описанных ниже процедур, имя, которое появляется в элементе таблицы экспорта в кодовом модуле, является соответствующей строкой, показанной ниже в разделах 9.1.4-9.1.7.
9.1.1.1. Загрузка объекта управления.
В одном варианте осуществления прежде чем механизм сможет произвести вызовы процедур управления, ему необходимо загрузить кодовый модуль объекта управления в виртуальную машину. В одном варианте осуществления в одну УМ загружается только один кодовый модуль.
9.1.1.2. Атомарность.
В одном варианте осуществления механизм гарантирует, что вызовы процедур в программах управления являются атомарными в отношении ресурсов, выделяемых процедуре, например, базы данных объектов (или состояний). Таким образом, в этом варианте осуществления, механизм должен гарантировать, что эти ресурсы остаются неизменными в ходе выполнения любой процедуры, которую он вызывает. Для этого можно эффективно блокировать эти ресурсы при вызове процедуры, или можно запретить одновременное выполнение нескольких УМ. Однако механизму не нужно гарантировать, что эти ресурсы останутся неизменными при последующих вызовах процедуры.
9.1.2. Протокол управления.
В одном варианте осуществления, именование процедур, входной/выходной интерфейс и структуры данных для каждой процедуры в кодовом модуле, вместе образуют протокол управления. Протокол, реализованный кодовым модулем, указан в поле рго1осо1 объекта управления. Описанный ниже иллюстративный протокол управления будем называть Стандартным протоколом управления, и его идентификатор (значение поля ’ргоЮсоГ) есть 1Шр:/Лу\\лг.ос1ори5-бгт.сот/5рес5/5ср-1_0.
В одном варианте осуществления прежде чем механизм ΌΚΜ загрузит кодовый модуль и вызовет процедуры в программе управления, ему нужно гарантировать, что взаимодействие с программой управления будет соответствовать спецификации конкретного ίά протокола, указанного в поле «протокол». Это включает в себя любую гарантию относительно особенностей виртуальной машины, которые необходимо реализовать, гарантии относительно размера пространства адресов, доступного программе управления, и т.п.
Протоколы управления, например Стандартный протокол управления, можно усовершенствовать со временем без необходимости создавать новую спецификацию протокола. Пока изменения, вносимые в протокол, согласуются с предыдущими ревизиями спецификации, и пока существующие реализации механизма ΌΚΜ, а также существующие программы управления, которые согласуются с этим протоколом, продолжают осуществляться согласно спецификации, изменения считаются совместимыми. Такие изменения могут включать в себя, например, новые типы действий.
9.1.3. Тип байт-кода.
В вышеописанном иллюстративном варианте осуществления, предусматривающем Стандартный протокол управления, тип байт-кодового модуля это Байт-кодовый модуль Р1апк1оп версия 1.0. В этом иллюстративном варианте осуществления, значение поля ’Чуре объекта управления есть
- 62 012918
1Шр://\\л\л\-.ос1ори5-6гт. сот/8рес§/ркст-1_0.
9.1.4. Общие процедуры управления.
Общие процедуры - это процедуры, которые применимы для объектов управления в целом, и не предназначены для данного действия или ограничения по связи. В одном иллюстративном варианте осуществления используются следующие общие процедуры управления.
9.1.4.1. Соп1го1.1пН
Эта процедура является необязательной (т.е. она не требуется во всех объектах управления). Если эта процедура используется, механизм вызывает ее один раз до вызова любой другой процедуры управления. Процедура не имеет аргументов и возвращает Яе5и11Со6е в вершину стека в качестве выхода. Яе8иНСо6е равен 0 в случае успеха или отрицательному коду ошибки в случае неудачи. В одном варианте осуществления, если Яе8и11Со6е не равен 0, механизм прерывает текущую операцию объекта управления и не делает никаких дополнительных вызовов процедур для этого объекта управления.
9.1.4.2. СогИгоЮехспЬе
Эта процедура является необязательной. Процедура вызывается, когда приложение запрашивает описание смысла правил, представленных программой управления в целом (т.е. не для конкретного действия). Процедура не имеет аргументов и возвращает Яе8иНСо6е и 81аЦ.15В1оскРоИ11ег в вершину стека в качестве выходов, где Яе§и11Со6е является целочисленным значением (0 если процедура завершена успешно, или, в противном случае, отрицательный код ошибки), и где 81а1и&В1оскРот1ег это адрес стандартного Ех1еп6е681аЦ.15В1оск. Ех1еп6е681а1и5В1оск содержит информацию, которую приложение может интерпретировать и использовать для предоставления пользователю информации относительно смысла правил, представленных программой управления.
9.1.4.3. Соп1го1.Яе1еа§е
Эта процедура является необязательной. Если эта процедура существует, механизм ΌΚΜ вызывает ее один раз после того, как ему уже не нужно вызывать какую-либо другую процедуру для объекта управления. Никакая другая процедура не будет вызвана для объекта управления, пока не будет инициировано новое использование объекта управления (в каковом случае, снова будет вызвана процедура Соп1го1.1пН). Процедура не имеет аргументов и возвращает Яе5и11Со6е в вершину стека в качестве выхода.
Яе8иНСо6е равен 0 в случае успеха или отрицательному коду ошибки в случае неудачи.
9.1.5. Процедуры АсНоп
Всякое возможное действие имеет имя (например, «воспроизведение», «перенос», «экспорт» и т.д.). В одном иллюстративном варианте осуществления, для данного действия <Ас11оп>, заданы следующие имена процедур (где <Ас1юп> обозначает фактическое имя действия (например, р1ау, ЯапкГег, ехрой, и т.д.)).
9.1.5.1. Соп1го1.ЛсНоп5.<ЛсНоп>.11Щ
Эта процедура является необязательной. Если она существует, механизм вызывает ее один раз до того, как вызвать какую-либо другую процедуру для этого действия. Процедура не имеет аргументов и возвращает Яе§иНСо6е в вершину стека в качестве выхода. Яе5и11Со6е равен 0 в случае успеха или отрицательному коду ошибки в случае неудачи. В одном варианте осуществления, если Яе§и11Со6е не равен 0, механизм прерывает текущее действие и не делает никаких дополнительных вызовов процедур для этого действия в этом объекте управления.
9.1.5.2. Соп1го1.ЛсНоп5.<ЛсНоп>.СНеск
В рассматриваемом иллюстративном варианте осуществления, эта процедура является обязательной и вызывается для проверки, без фактического осуществления данного действия, каково было бы состояние возврата, если бы для этого действия была вызвана процедура РегГогт. Важно, чтобы эта процедура не имела побочных эффектов. Заметим, что если процедура РегГогт также не имеет побочных эффектов, элементы СНеск и РегГогт в таблице элементов объекта управления могут указывать на ту же процедуру. Эта процедура имеет те же входы и выходы, что и описанная ниже процедура РегГогт.
9.1.5.3. Соп1го1.ЛсНоп5.<Лс1юп>.РегГогт
В одном варианте осуществления эта процедура является обязательной и вызывается, когда приложение собирается осуществить действие. Процедура не имеет аргументов и возвращает Яе8и11Со6е и 81аЦ15В1оскРот1ег в вершину стека в качестве выходов, где Яе5и11Со6е это целочисленное значение (0 если процедура завершена успешно, или, в противном случае, отрицательный код ошибки), и где 81а1изВ1оскРоН11ег это адрес стандартного Ех1еп6е681а1и5В1оск. Заметим, что в одном варианте осуществления Яе5и11С.’о6е успеха (т.е. 0) не означает, что запрос удовлетворен. Он означает только то, что процедура выполнена без ошибок. Удовлетворен или отклонен запрос, указывает Ех1еп6е681а1и5В1оск. Однако, если Яе5и11Со6е указывает неудачу, приложение хоста реагирует, как будто запрос отклонен. Например, в одном варианте осуществления категория структуры 81а1и5В1оск должна быть АСТЮ^ОЕМЕО, или возвращаемый Ех1еп6е681аЦ.15В1оск должен отвергаться, и тогда приложение хоста прерывает действие.
При осуществлении действия нужно вызывать только процедуру РегГогт. Механизму не нужно предварительно вызывать процедуру СНеск. Реализация процедуры РегГогт может предусматривать внутренний вызов процедуры С1еск, по ее собственному усмотрению, но не следует полагать, что система будет заранее вызывать процедуру СНеск.
- 63 012918
9.1.5.4. Соп1го1. Лсйопк.< Лсйоп>.Пексг1Ье
Эта процедура является необязательной и вызывается, когда приложение запрашивает описание смысла правил и условий, представленных программой управления для данного действия. Процедура не имеет аргументов и возвращает КекикСобе и 81аШкВ1оскРок11ег в вершину стека в качестве выходов, где КекикСобе это целочисленное значение (0 если процедура завершена успешно, или, в противном случае, отрицательный код ошибки), и где 81а1икВ1оскРо1п1ег это адрес стандартного Ех1епбеб81а1икВ1оск.
9.1.5.5. Соп1го1. Лсйоп8.<Лсйоп>.Ке1еаке
Эта процедура является необязательной. Если она существует, она вызывается один раз, когда механизму ΌΚΜ уже не нужно вызывать какие-либо другие процедуры для данного действия. Для данного действия не вызываются никакие другие процедуры, пока не будет инициировано новое использование действия (в каковом случае, снова будет вызвана процедура Ιηίΐ). Процедура не имеет аргументов и возвращает КекикСобе в вершину стека в качестве выхода. КекикСобе равен 0 в случае успеха и отрицательному коду ошибки в случае неудачи. Если КекикСобе не равен 0, механизм не делает никаких дополнительных вызовов процедур для данного действия.
9.1.6. Процедуры ограничения по связи.
В одном варианте осуществления, когда в объект «связь» внедрен объект управления, механизм ΌΚΜ вызывает процедуры ограничения по связи в этом объекте управления для проверки действительности объекта «связь». В одном иллюстративном варианте осуществления используются следующие процедуры ограничения по связи.
9.1.6.1. Соп1го1.Ьшк.Сопк1гат1.1пй
Эта процедура является необязательной, и, если существует, вызывается только один раз прежде, чем будет вызвана какая-либо другая процедура для данного ограничения по связи. Процедура не имеет аргументов и возвращает КекикСобе в вершину стека в качестве выхода. КекикСобе равен 0 в случае успеха и отрицательному коду ошибки в случае неудачи. Если КекикСобе не равен 0, механизм считает, что ограничение по действительности для объекта «связь» не выполнено, и блокирует дальнейшие вызовы процедур для объекта управления связи.
9.1.6.2. Соп1го1.Ь1пк.Сопк1га1п1. Скеск
В рассматриваемом иллюстративном варианте осуществления, эта процедура является обязательной и вызывается для проверки, выполняется ли ограничение по действительности для данной связи. Процедура не имеет аргументов и возвращает КекикСобе и 81аШкВ1оскРойИег в вершину стека в качестве выходов, где КекикСобе это целочисленное значение (0 если процедура завершена успешно, или, в противном случае, отрицательный код ошибки), и где 81аШкВ1оскРойИег это адрес стандартного ЕХепбеб81аШкВ1оск. Если КекикСобе не равен 0, механизм считает, что ограничение по действительности для объекта «связь» не выполнено, и блокирует дальнейшие вызовы процедур для объекта управления связи. Даже если КекикСобе равен 0 (успех), это не означает, что ограничение выполнено; это означает только то, что процедура выполнена без ошибок.
Выполнено ограничение или нет, указывает 81а1икВ1оск.
9.1.6.3. Соп1го1.Ьшк.Сопк1таш1.ПекспЬе
Эта процедура является необязательной и вызывается, когда приложение запрашивает описание смысла ограничения, представленного программой управления для данной связи. Процедура не имеет аргументов и возвращает КекикСобе и 81аШкВ1оскРойИег в вершину стека в качестве выходов, где КекикСобе это целочисленное значение (0 если процедура завершена успешно, или, в противном случае, отрицательный код ошибки), и где 81аШкВ1оскРот1ег это адрес стандартного Ех1епбеб81а1икВ1оск.
9.1.6.4. Соп1го1.Ь1пк.Сопк1гаш1.Ке1еаке
Эта процедура является необязательной и, если существует, вызывается механизмом после того, как механизму уже не нужно вызывать какую-либо другую процедуру для данного ограничения. Процедура не имеет аргументов и возвращает КекикСобе в вершину стека в качестве выхода. КекикСобе равен 0 в случае успеха и отрицательному коду ошибки в случае неудачи. Согласно рассматриваемому варианту осуществления, после вызова этой процедуры, нельзя вызвать никакую другую процедуру для данного ограничения, пока не будет инициирован новый цикл (в каковом случае, снова вызвается процедура 1п11). Аналогично, если КекикСобе не равен 0, механизм не делает никаких дополнительных вызовов процедур для данного ограничения по связи.
9.1.7. Процедуры агента.
В одном варианте осуществления агент это объект управления, который призван выполняться от имени сущности. Агенты обычно используются в контексте взаимодействия услуг между двумя конечными точками, когда одна конечная точка должна выполнять код некоторой виртуальной машины в контексте второй конечной точки и, возможно, получать результат этого выполнения. В одном варианте осуществления объект управления может содержать несколько агентов, и каждый агент может содержать любое количество процедур, которые могут выполняться; однако, на практике, агенты обычно имеют по одной процедуре.
В одном иллюстративном варианте осуществления заданы следующие точки входа для агентов, где <Лдеп1> это строка имени, которая является ссылкой на фактическое имя агента.
- 64 012918
9.1.7.1. Соп1го1.Адеп1к.<Лдеп1>.1ш1
Эта процедура является необязательной и, если она существует, механизм вызывает ее один раз до того, как какая-либо другая процедура будет вызвана для данного агента. Процедура не имеет аргументов и возвращает КекиИСобе в вершину стека в качестве выхода. КекиИСобе равен 0 в случае успеха и отрицательному коду ошибки в случае неудачи.
9.1.7.2. Соп!го1.Адеп1к.<Адеп1>.Кип
В рассматриваемом иллюстративном варианте осуществления, эта процедура является обязательной и является главной процедурой агента. Процедура не имеет аргументов и возвращает КекиИСобе, Ке1игпВ1оскАббгекк и Ке1игпВ1оск8|/е в вершину стека в качестве выходов. КекиИСобе это целочисленное значение (0 если процедура завершена успешно, или, в противном случае, отрицательный код ошибки), Ке1игпВ1оскАббгекк это адрес блока памяти, предназначенного для хранения данных, которые агентский код должен возвратить вызывающей сущности (если процедура ничего не должна возвращать, адрес равен 0), и КеШгпВ1оск8|/е это размер в байтах блока памяти по адресу Ке1игпВ1оскАббгекк. В одном варианте осуществления, если Ке1игпВ1оскАббгекк равен 0, то значение КеШгпВ1оск8|/е также равно 0.
9.1.7.3. Соп1го1.Лдеп1к.<Лдеп1>.Пексг1Ье
Эта процедура является необязательной и вызывается, когда приложение запрашивает описание данного агента. Процедура не имеет аргументов и возвращает КекиИСобе и 81а1икВ1оскРот1ег в вершину стека в качестве выходов, где КекиИСобе это целочисленное значение (0 если процедура завершена успешно, или, в противном случае, отрицательный код ошибки), и где 81а1икВ1оскРот1ег это адрес стандартного Ех1епбеб81аШкВ1оск.
9.1.7.4. Соп!го1. Лдеп1к.<Лдеп1>.Ке1еаке
Эта процедура является необязательной и, если она существует, механизм вызывает ее один раз, когда механизму уже не нужно вызывать какие-либо другие процедуры для этого агента.
Для этого агента не будет вызвана никакая другая процедура, пока не будет инициирован новый цикл (в каковом случае, снова будет вызвана процедура 1ш1). Процедура не имеет аргументов и возвращает КекиИСобе в вершину стека в качестве выхода. КекиИСобе равен 0 в случае успеха и отрицательному коду ошибки в случае неудачи.
9.2. Расширенные блоки состояний.
Нижеследующие иллюстративные определения применимы к структурам данных Ех1епбеб81а1икВ1оск, возвращаемым несколькими вышеописанными процедурами согласно иллюстративным вариантам осуществления. Примеры структур данных Ех1епбеб81аШкВ1оск описаны в связи с описанием виртуальной машины.
В одном варианте осуществления, не существует глобальных флагов для Ех1епбеб81аШкВ1оск. В этом варианте осуществления, программы управления задают поле С1оЬа1Е1ад структуры Ех1епбеб81а1иВ1оск равным 0.
9.2.1. Категории.
В нижеследующих разделах заданы значения для поля Са1едогу структур Ех1епбеб81аШкВ1оск согласно одному варианту осуществления. В одном варианте осуществления, ни одна из этих категорий не имеет подкатегорий, и поэтому значение поля 8иЬСа1едогу структур Ех1епбеб81а1икВ1оск задано равным 0.
В одном варианте осуществления заданы следующие коды категорий.
9.2.1.1. Процедуры СЬеск и РегГогш для действий.
Значение
Имя
Описание
Α0ΤίΟΝ_ΰΚΑΝΤΕΕ> Приложение авторизовано использовать ключи контента.
которыми управляет программа управления, для выполнения запрошенного действия.
Список параметров возвращаемой структуры
Ех£епс1ес15ЬаЪи5131оск не должен содержать никаких параметров ограничения, но может
- 65 012918 содержать параметры обязательства и/или обратного вызова.
АСТ1СЖ_ОЕЫ1ЕВ Приложение не авторизовано использовать ключи контента которыми управляет программа управления для выполнения запрошенного действия.
Когда действие отменено.
программа управления должна включить список параметров возвращаемой структуры
ЕхСепс1ес15Ъа-Ь.изВ1оск одно или несколько ограничений которые не были выполнены, что привело к отмене действия (ограничения которые не оценивались ограничения, которые не привели к отмене действия следует пропустить).
В одном варианте осуществления список параметров возвращаемой структуры
Ех£епс1ес13СаСизВ1оск не должен содержать никаких параметров обязательства или обратного вызова.
В одном варианте осуществления в контексте параметров Ε^η^άδΐαΐαδΒ^^ возвращаемых процедурами действия, ограничение означает условие, которое должно быть выполнено, или критерий, которому нужно удовлетворить, чтобы процедура возвратила ЕхЮпсЫ^ШнЦИоск с категорией АСΊΊΌΝ ОКАОТЕБ.
В одном варианте осуществления значения поля ЬосаГНадз, общие для обеих вышеописанных категорий, включают в себя:
Битовый
Имя
Описание индекс (0 это
ЬЗВ)
ОВЫСАТЮИ Ы0Т1СЕ
Список параметров содержит один или несколько параметров которые относятся обязательствам
САЬЬВАСК ЫОТ1СЕ
Список параметров содержит один или несколько параметров.
которые относятся к обратным вызовам
ΟΕΝΕΒΙΟ ΟΟΝΒΤΒΑΙΝΤ
Список параметров содержит один или несколько параметров которые относятся к общим ограничениям
ТЕМРОВАЬ ΟΟΝΒΤΒΑΙΝΤ
Список параметров содержит один или несколько параметров, которые относятся к временным ограничениям
5РАТ1АЬ СО№ТКА1ЫТ
Список параметров содержит один или несколь ко параметров которые относятся пространственным ограничениям
СЯСТОР 00Ν5ΤΚΑΙΝΤ
Список параметров содержит один или несколько параметров, которые относятся к групповым ограничениям
РЕУТСЕ 00Ν8ΤΚΑΙΝΤ
Список параметров содержит один или несколько параметров которые относятся ограничениям по устройству
- 66 012918
ΟΟζΙΝΤΕΗ_ΟΟΝ3ΤΡΑΙΝΤ Список параметров содержит один или несколько параметров, которые относятся к ограничениям по счетчику
Согласно вышеприведенной таблице, упомянутый в ней список параметров представляет собой поле Рагате!ега структуры данных Ех!епбеб8!а!и5В1оск.
9.2.1.2. Коды категорий процедур ЭехспЬе.
В одном варианте осуществления для процедур ЭехспЬе коды категорий не заданы. В одном варианте осуществления, к процедурам ЭехспЬе применяются те же локальные флаги, которые заданы для процедур Лсбоп, и процедуры ЭехспЬе должны включать в возвращаемую ими структуру Ех!епбеб8!а!ивВ1оск параметр по имени 'Оекспрйоп', описанный ниже. В одном варианте осуществления, процедуры ЭехспЬе не содержат в возвращаемой ими структуре Ех!епбеб8!а!и5В1оск никаких параметров обязательства или обратного вызова; однако процедуры ЭехспЬе должны включать в возвращаемую ими структуру Ех!епбеб8!а!ивВ1оск параметры, описывающие некоторые или все ограничения, применимые к соответствующему действию или ограничению по связи.
9.2.1.3. Коды категорий процедур для ограничения по связи.
Значение Имя Описание
О ЫЫК_УАЫР Связь, ограниченная этой программой управления, действительна.
Список параметров возвращаемой ЕЗВ не должен содержать никаких параметров ограничения, и, в одном варианте осуществления, не должен содержать параметров обязательства или обратного вызова
ЫМК_1Ы7АЬЮ Связь, ограниченная этой программой управления недействительна.
Когда связь недействительна, программа управления должна включить в список параметров возвращаемой ЕЗВ одно или несколько ограничений, которые не были выполнены и привели к недействительности связи (ограничения, которые не оценивались, и ограничения, которые не привели к отмене действия, следует пропустить).
В одном варианте осуществления, список параметров возвращаемой ЕЗВ не должен содержать никаких параметров обязательства или обратного вызова.
В одном варианте осуществления, для каждой из этих категорий применяются те же локальные флаги, которые заданы для процедур Лсйоп.
В одном варианте осуществления, в контексте параметров Ех!епбеб8!а!и8В1оск, возвращаемых процедурами для ограничения по связи, ограничение означает условие, которое должно быть выполнено, или критерий, которому нужно удовлетворить, чтобы процедура возвратила Ех!епбеб8!а!и&В1оск с категорией υΝΐ<_νΑυο.
9.2.2. Времена жизни кэша.
Поле СасйеОигайоп структуры Ех!епбеб8!а!и5В1оск указывает период действия информации, закодированной в Ех!епбеб8!а!и5В1оск. Когда Ех!епбеб8!а!и5В1оск имеет ненулевой период действия, это оз
- 67 012918 начает, что Ех1еп6е681а1и5В1оск можно сохранять в кэше, и что, в течение этого периода времени, точно такой же процедуры с теми же самыми параметрами возвратит точно такую же структуру Ех1еп6е68!а1н&В1оск, поэтому приложению хоста можно возвращать кэшированное значение вместо того, чтобы вызывать процедуру.
9.2.3. Параметры.
Некоторые параметры используются для переноса подробной информации о состоянии возврата, а также связки переменных для обработки шаблонов (см. раздел 9.4).
В одном варианте осуществления, кроме обязательств и обратных вызовов, все описанные здесь ограничения имеют своей единственной целью помощь в классификации и отображении приложения хоста, а не применение правил пользования. За применение правил отвечает программа управления.
В одном варианте осуществления, параметры, заданные в нижеследующем разделе, кодируются либо как Рагате1егВ1оск, если никакие флаги параметра не применимы, либо как Ех1еп6е6Рагате1егВ1оск, если один или несколько флагов применимы. Ниже описаны иллюстративные флаги.
9.2.3.1. Описание.
Имя параметра: Иекспрйоп.
Тип параметра: Уа1иеЬщ1.
Описание: Список параметров описания. Каждое значение в списке имеет тип Рагате1ег или Ех1еп6е6Рагате1ег. В одном варианте осуществления, заданы следующие параметры: ОеГаи11. 81юй и Ьопд. Каждый из них, если присутствует, имеет в качестве значения Ш одного из ресурсов объекта управления. Этот ресурс должен содержать полезную нагрузку в виде текста или полезную нагрузку в виде шаблона. Если ресурс является шаблоном, он обрабатывается для получения текстуального описания результата (описания либо всей программы управления, либо конкретного действия). Шаблон обрабатывается с использованием, в качестве связок переменных, других параметров из списка, в котором присутствует параметр 'Иекспрйоп'.
В одном варианте осуществления, описания '81югГ и 'Ьопд' могут быть включены только, если включено также описание 'ОеГаиН'.
| Имя | Тип | Описание | |
| Ое£аи1б | йезоигсе | 16 ресурса, который содержит нормальный текст или шаблон описания | |
| ЗЬогХ | Кезоигсе | Ιά ресурса, который содержит текст или шаблон описания | короткий |
| Ьопд | Кезоигсе | Ιά ресурса, который содержит текст или шаблон описания | длинный |
9.2.3.2. Ограничения.
В одном варианте осуществления, параметры ограничения сгруппированы в списки, которые содержат ограничения сходных типов. В одном варианте осуществления, заданы стандартные ограничения для некоторых типов. В одном варианте осуществления, объекты управления могут возвращать параметры ограничения, которые не включены в набор стандартных ограничений, при условии, что имя параметра ограничения является υΚΝ в пространстве имен, что гарантирует уникальность этого имени. Такие ограничения могут включать в себя ограничения, относящиеся к поставщику, или ограничения, установленные в других спецификациях.
9.2.3.2.1. Общие ограничения.
Имя параметра: бепепсСопйгатК
Тип параметра: Уа1иеЬщ1.
Описание: Список общих ограничений, которые можно применять. Каждое значение в списке имеет тип Рагате1ег или Ех1еп6е6Рагате1ег.
В одном варианте осуществления, общие ограничения являются ограничениями, которые не принадлежат никакому другому типу ограничения, заданному в этом разделе. В одном варианте осуществления, никакие общие параметры ограничения не заданы.
9.2.3.2.2. Временные ограничения.
Имя параметра: ТетрогаЮопйгатК
Тип параметра: Уа1иеЬщ1.
Описание: Список временных ограничений, которые можно применять. Каждое значение в списке имеет тип Рагате1ег или Ех1еп6е6Рагате1ег. Временные ограничения это ограничения, которые относятся к времени, дате, длительности и/или т.п. В одном варианте осуществления заданы следующие временные параметры ограничения:
- 68 012918
Описание
ЫоЪВеГоге
Оа£е
Дата до которой действие
МоДА^Пег
Ра£е
МоЪСигхпд
Уа1иеЫ8·!:
запрещено
Дата после которой действие запрещено
Список из 2 значений типа ЭаЪе.
Первое значение это начало периода, а второе конец, периода который исключен
Ыо1ЬопдегТЪап
ТпЕедег
Максимальное число секунд после первого использования. В одном варианте осуществления это значение является беззнаковым
ЫсФМогеТИап
1пЪедег
Максимальное число секунд совокупного времени использования. В одном варианте осуществления, это значение является беззнаковым
9.2.3.2.3. Пространственные ограничения.
Имя параметра: 8рз11з1С’оп51гз1п15.
Тип параметра: Уа1иеЬ181.
Описание. Список пространственных ограничений, которые можно применять. В одном варианте осуществления, каждое значение в списке имеет тип Рагате!ег или Ех1епбебРагате1ег. Пространственные ограничения это ограничения, которые относятся к физическим положениям. В одном варианте осуществления, никакие стандартные пространственные ограничения не заданы.
9.2.3.2.4. Групповые ограничения.
Имя параметра: С^оирСои8ΐ^а^иΐ8.
Тип параметра: Уа1иеЫ81.
Описание: Список групповых ограничений, которые можно применять. Каждое значение в списке имеет тип Рагате!ег или Ех1епбебРагате1ег. Групповые ограничения это ограничения, которые относятся к группам, групповой принадлежности, идентификации групп и/или т. п. В одном варианте осуществления заданы следующие параметры:
Имя Тип Описание
МетЬегвЫрНедихгес! Кезоигсе Ιά ресурса, который содержит текст или шаблон для имени или идентификатора группы, принадлежность к которой требуется
1сЕеп£1£уР1еди1гес1 йезоигсе Ιά ресурса, который содержит текст или шаблон для имени или идентификатора отдельной сущности
9.2.3.2.5. Ограничения по устройству.
Имя параметра: ПеукеСопзйшШз.
Тип параметра: Уа1иеЫ81.
Описание: Список ограничений по устройству, которые можно применять. Каждое значение в списке имеет тип Рагате!ег или ΈxΐеиάеάРа^атеΐе^. Ограничения по устройству это ограничения, которые относятся к характеристикам устройства, например признакам, атрибутам, именам, идентификаторам и/или т.п. В одном варианте осуществления заданы следующие параметры:
Имя Тип Описание
ΟβνϊοβΤγρβΗβφΐίΓβά
Кезоигсе
Ιά ресурса который содержит текст или шаблон для требуемого
ОеухоеГеаЕигеКедитгеЗ
Кезоигсе типа устройства хоста
Ιά который ресурса
| содержит | текст | или |
| шаблон | для | имени |
| признака. | который | должно |
иметь устройство хоста
ЗЪгхпд Ιά, который должно иметь
0еу1се1с1Веди1.гес1
- 69 012918 устройство. Этот Ιά может быть любой строкой, которую можно использовать для идентификации устройства (например, именем устройства, серийным номером устройства, ίά. узла и/или т.п,),
9.2.3.2.6. Ограничения по счетчику.
Имя параметра:
Тип параметра: ν;·ι1ικΕί8ΐ.
Описание: Список ограничений по счетчику, которые можно применять. Каждое значение в списке имеет тип Рагате1ег или ΕxΐеиάеάΡа^атеΐе^. Ограничения по счетчику это ограничения, которые относятся к значениям счетчика, например, счетчику воспроизведения, накопленному значению счетчика и/или т.п. В одном варианте осуществления, никакие стандартные ограничения по счетчику не заданы.
9.2.3.3. Флаги параметра.
В одном варианте осуществления, следующие флаги можно использовать для всех параметров, описанных в разделе 9.2.3, когда они закодированы в виде Εxΐеиάеά8ΐаΐи8В1οск:
| Битовый индекс (0 это Ь8В) | Имя | Описание |
| 0 | сктсдь | Приложение хоста должно понимать семантику, связанную с этим параметром. В противном случае, всю структуру Ех1епдей81аП15В1оск следует считать непонятной и отвергать. В одном варианте осуществления, этот флаг не следует использовать для параметров, имеющих описательный характер. |
| 1 | НЦМАИКЕАИАВЬЕ | Этот параметр представляет значение, имя и значение которого пригодны для отображения на текстовом или графическом пользовательском интерфейсе. Любой параметр, для которого этот флаг не установлен, следует резервировать для приложения хоста и не следует показывать пользователю. Для значений параметра типа Везоигсе, он не является 10 ресурса, но указывает, что полезная нагрузка данных ресурса, указываемая 10, воспринимаема человеком. |
9.4. Обязательства и обратные вызовы.
В одном варианте осуществления, определенные действия, когда они разрешены, требуют дополнительного участия приложения хоста. Обязательства представляют операции, которые должно осуществлять приложение хоста после использования ключа контента, которые они запрашивают. Обратные вызовы представляют вызовы одной или нескольких процедур программы управления, которые должно осуществлять приложение хоста после использования ключа контента, которые они запрашивают.
В одном варианте осуществления, если приложение встречает какое-либо критическое обязательство или обратный вызов, которое(ый) оно не поддерживает или не понимает (например, потому, что тип обязательства был задан после реализации приложения), оно должно отказаться продолжать действие, для которого был возвращен этот параметр обязательства или обратного вызова. В одном варианте осуществления, критическое (ий) обязательство или обратный вызов указывается путем задания флага параметра СШТ1САБ для параметра, который его описывает.
Если управление имеет побочные эффекты (например, уменьшение счетчика воспроизведения), оно должно использовать обратный вызов ОпАссер!, чтобы потребовать от приложения хоста вызов определенной процедуры, если оно способно понимать все критические обязательства и обратные вызовы и выполнять их. Побочный эффект имеет место в процедуре обратного вызова. В одном иллюстративном
- 70 012918 варианте осуществления, реализации должны понимать и реализовывать обратный вызов ОиЛссер!, поскольку это может быть полезно для предотвращения преждевременного возникновения побочных эффектов (например, обновлений базы данных состояний) (например, прежде чем приложение хоста определит, что оно неспособно выполнить данное(ый) критическое обязательство или обратный вызов и должно прекратить выполнение действия), что обеспечивает меру транзакционной атомарности.
9.4.1. Параметры.
Следующие параметры задают несколько типов обязательств и обратных вызовов, которые могут возвращаться в структурах данных Ех1епбеб81аШкВ1оск.
9.4.1.1. Обязательства.
Имя параметра: ОЬНдаЕопк.
Тип параметра: Уа1иеЫк1.
Описание: Список параметров обязательства. Каждое значение в списке имеет тип Рагаше1ег или ЕхОепбебРагашеОег. В одном варианте осуществления заданы следующие параметры обязательства:
| Имя | Тип | Описание | |||
| КипА§еп1ОпРеег | Уа1ие1л$( | Приложение хоста должно направить объект управления агента для выполнения на равноправном устройстве сеанса протокола, выполняющегося в данный момент. | |||
| Тип | Описание | ||||
| 8ΐτίη§ | Ιά объекта управления, который содержит агент для выполнения. | ||||
| 8ΐΠΠ§ | Имя агента для выполнения. | ||||
| [Ше^ег | 10 экземпляра. Это значение используется для уникальной идентификации экземпляра обязательство этого агента Этот ίθ также позволяет системе | ||||
| коррелировать обязательство этого агента с параметром обратного вызова ОпА§еп1Сотр1е1юп. | |||||
| 81пп§ | Ιά контекста. Этот 10 виден агенту, выполняющемуся на равноправном устройстве, по пути контекста сеанса Ноя ОЬ]сс1 агента: Ос1ори5/А£еп1/Рагате1ег5/8е$яо п/Соп1ех1Ю. | ||||
| Уа1ие1л «1 | Список значений типа РагатеХег. Агент видит все эти параметры как входные параметры. |
9.4.1.2. Обратные вызовы.
Имя параметра: Са11Ьаскк.
Тип параметра: Уа1иеЫк1.
Описание: список параметров обратного вызова. Каждое значение в списке имеет тип Рагаше1ег или ЕхОепбебРагашеОег. В одном варианте осуществления заданы следующие параметры обратных вызовов:
- 71 012918
| Имя | Тип | Описание |
| ОпАссер1 | СаНЬаск | Приложение хоста должно осуществлять обратный вызов, если оно способно понимать все параметры критических обязательств и обратных вызовов, содержащиеся в этой Е8В. В одном варианте осуществления, может существовать, самое большее, один параметр обратного вызова ОпАссерГ в списке параметров обратных вызовов. Если в списке указаны другие параметры обратных вызовов, ОпАссер! выполняется в первую очередь. |
| ОпТ1те | Уа1иеЬ|з4 | Приложение хоста должно осуществлять обратный вызов после указанной/го даты/времени. |
| Тип | Описание | |
| Оа(е | Дата, после которой приложению хоста нужно осуществлять обратный вызов. | |
| СаНЬаск | Процедура для обратного вызова и соответствующий куки. | |
| ОпТ1теЕ1арзе<1 | Уа1иеЫз1 | Приложение хоста должно осуществлять обратный вызов по истечении указанного срока (отсчет начинается, когда приложение хоста фактически осуществляет действие, на которое дано разрешение). |
| Тип | Описание | |
| 1пГееег | Число секунд. Значение является беззнаковым. | |
| СаНЬаск | Процедура для обратного вызова и соответствующий куки. | |
| ΟπΕνβηί | Уа1иеЬ1з1 | Приложение хоста должно осуществлять обратный вызов, когда наступает определенное событие. |
| Тип | Описание | |
| 8ипч> | Имя события | |
| ЬПе^ег | Флаги события (целочисленное значение интерпретируется как битовое поле) | |
| 1л1е§ег | Параметр события | |
| СаНЬаск | Процедура для обратного вызова и соответствующий куки. | |
| Более подробные сведенья о событиях см. в разделе о событиях. | ||
| ОпА|>еп1Сотр1е1к>п | Уа1иеЬ1з1 | Приложение хоста должно осуществлять обратный вызов, когда выполнение агента, |
- 72 012918 указанного в одном из параметров обязательства, завершено или не удалось.
| Тип | Описание |
| 1п1е§ег | Ιά экземпляра агента. и экземпляра, указанный в обязательстве агента. |
| СаПЬаск | Процедура для обратного вызова и соответствующий куки. |
При осуществлении обратного вызова, приложение хоста должно обеспечивать следующий Аг£шпеп15В1оск:
| Тип | Кодировка | Описание |
| 32- битовое целое | 4 байта в обратном порядке следования байтов | Код состояния «завершение» |
| 32- битовое целое | 4 байта в обратном порядке следования байтов | Код результат агента |
| Массив 8- битовых байтов | Последовательность байтов | КеШтЕМоск агента |
Значение кода состояния завершения равно О, если агент выполнен нормально, или отрицательному коду ошибки, если нет.
Ке1игпВ1оск агента это данные, возвращаемые агентом. Он отсутствует, если не удалось выполнить агент (код состояния завершения не равен 0).
В одном варианте осуществления тип 'Са11Ьаск', указанный в вышеприведенной таблице, представлен как Уа1иеЫк1В1оск с тремя элементами Уа1иеВ1оск:
Тип значения
1пГе£ег
Описание
Ιϋ типа обратного вызова. В одном варианте осуществления заданы два типа обратных вызовов:
Описание
Все запросы на обратные вызовы, ожидающие рассмотрения, и активные обязательства отменяются после вызова процедуры обратного вызова. Процедура обратного вызова возвращает Е$В, которая указывает, может ли, и как, приложение может продолжать текущую операцию.
Вызывается процедура обратного вызова, тогда как все остальные запросы на обратные вызовы, ожидающие рассмотрения, и активные обязательства остаются в силе. Процедура обратного вызова возвращает простой код результата.
Приложение может продолжать текущую операцию, если код результата не указывает неудачу.
| 5ΐτίη§ | Точка входа в вызов в кодовый модуль, В одном варианте осуществления, это должен быть один из элементов таблицы экспорта кодового модуля для того же объекта управления, который содержит процедуру, возвратившую Е8В с этим параметром. |
| 1пСе^ег | Куки. Это значение передается в стек вызываемой процедуры. |
- 73 012918
9.4.1.3. Флаги параметра.
В одном варианте осуществления используются те же самые флаги параметра, которые определены в предыдущем разделе. В одном варианте осуществления, обратные вызовы и обязательства, необходимые вызывающей сущности для реализации, помечаются как СШТ1САЦ чтобы приложение хоста не имело возможности игнорировать эти параметры.
9.4.2. События.
В одном варианте осуществления события указаны именем. В зависимости от типа события может существовать набор заданных флагов, которые дополнительно описывают событие. В одном варианте осуществления, если для конкретного события не задано никаких флагов, значение поля Над задается равным 0. Кроме того, некоторые события могут указывать, что некоторая информация должна передаваться процедуре обратного вызова при наступлении события. В одном варианте осуществления если от приложения хоста не требуется никакой специальной информации, приложение хоста должно совершать вызов с пустым Агдитеи!кВ1оск (см. описание интерфейса процедуры обратного вызова в разделе 3.3, ниже).
В одном варианте осуществления, если приложение хоста не понимает или не поддерживает имя события в параметре обратного вызова, помеченном СК1Т1САЬ, приложение хоста должно рассматривать этот параметр как непонятый СШТ1САЬ параметр (и действие, на которое запрошено разрешение, не должно осуществляться).
В одном варианте осуществления заданы следующие имена событий:
выраженное числом секунд после начала представления отсчитывается представления. Время представления относится к времени медиа-источника, а представление воспроизведения в реальном времени или после поиска). Время представления
Приложение хоста должно осуществлять обратный вызов, когда достигнуто или
Позиция в представлении мультимедиа это смещение метки вне диапазона всех меток в представлении.
превышено указанное представления (в ходе нормального представлении мультимедиа.
В одном варианте осуществления, при обратного осуществлении приложение хоста должно обеспечивать времени настенных (например, приостанавливав гея, представления не изменяется).
Приложение хоста должно осуществлять обратный вызов, происходит прямой доступ к произвольной точке в
представления, следующие данные в Агеитеп15В1оск:
| Тип | Кодировка | Описание |
| 32-битовое беззнаковое целое | 4 байта в обратном порядке следования байтов | Смещение позиции поиска |
| 32-битовое беззнаковое целое | 4 байта в обратном порядке следования байтов | Диапазон позиций поиска |
- 74 012918
Например, для представления длительностью 327 секунд, поиск 60-ой секунды можно представить смещением=60, диапазоном=327.
Вызывающая сущность выбирает единицу, которая соответствует измерению смещения и диапазона (это может быть единица времени, байт как единица размера или любая другая единица), при условии, что “метки” однородно распределены по всему представлению. Значение смещения должно быть меньше или равно значению диапазона.
9.4.3. Процедуры обратного вызова.
В одном варианте осуществления процедуры обратного вызова принимают один и тот же вход. !пры1: Вершина стека:
Соок<е
Аг§итеп1зВ]оск812е
...данные...
Соок1е: значение поля Соок1е, указанное в параметре обратного вызова.
Агдитеп1кВ1оск5>1/е: число байтов данных, передаваемых в стек под этим параметром. При вызове процедуры, стек содержит значение Агдцтеп1кВ1оск§17е, выданное вызывающей сущностью, указывающее размер блока аргументов на вершине, после которого следует Агдитеп1кВ1оск5>1/е байтов данных. В одном варианте осуществления, если размер не кратен 4, данные в стеке дополняются нулевыми байтами, чтобы гарантировать, что указатель стека остается кратным 4.
9.4.3.1. Обратные вызовы СΟNТINυΕ.
В одном варианте осуществления обратные вызовы типа СОКПИЦЕ (ΙΌ типа = 0) имеют следующий выход.
Ои1ри1: Вершина стека: _____________
КеяиИСобе !
КекиЙСобе: целочисленное значение. Значение результата равно 0, если процедура выполнена, или отрицательному коду ошибки, если произошла ошибка.
Описание: если КекиЙСобе указывает, что процедура обратного вызова выполнена (т.е. значение равно 0), приложение хоста может продолжать текущую операцию. Если КекиЙСобе указывает, что произошла ошибка, приложение хоста прерывает текущую операцию и отменяет все ожидающие обратные вызовы и обязательства.
9.4.3.2. Обратные вызовы КЕ8ЕТ.
Когда процедура управления указывает один или несколько обратных вызовов типа КЕ8ЕТ в Е8В, возвращаемой процедурой, приложение хоста вызывает любую указанную процедуру обратного вызова, когда условие для этого обратного вызова выполняется. В одном варианте осуществления, если выполняются условия любого из обратных вызовов, приложение хоста должно:
отменить все остальные ожидающие обратные вызовы;
отменить все текущие обязательства; обеспечить все необходимые параметры (если существуют) для этого обратного вызова; вызвать указанную процедуру обратного вызова.
Состояние возврата из процедуры указывает приложение хоста, если оно может продолжать осуществление текущей операции. В одном варианте осуществления, если в разрешении отказано, или не удается успешно выполнить процедуру, приложение хоста должно прервать осуществление текущей операции. Аналогично, если разрешение дано, приложение хоста должно подчиняться любому обязательству или обратному вызову, которое(ый) может быть возвращен(о) в Е8В, как если бы оно вызвало исходную процедуру Соп1го1.Асйопк.<Асйоп>.РегГогт. Предыдущие обязательства или спецификации обратных вызовов больше не имеют силы.
В одном варианте осуществления все процедуры, указанные как точки входа обратного вызова для этого типа обратного вызова имеют следующий выход.
Ои1ри1: Вершина стека:
КезикСо<1е
81а1п$В1оскРо1п1:ег
КекиЙСобе: целочисленное значение. Значение результата равно 0, если процедура выполнена, или
- 75 012918 отрицательному коду ошибки, если произошла ошибка.
8!а!икВ1оскРош!ег: адрес стандартного Ех!еп6е68!а!икВ1оск.
Описание: семантика возврата этой процедуры эквивалентна описанной для процедуры Соп!го1.Лсйопк.<Лс!1оп>.РегГогт.
9.5. Ресурсы Метаданных.
В одном варианте осуществления объекты управления могут содержать ресурсы метаданных, к которым можно обращаться через параметры, возвращаемые в структурах данных Ех1еп6е681а1икВ1оск. Ресурсы могут представлять собой простой текст, шаблоны текста или другие типы данных. Каждый ресурс идентифицируется посредством ΙΌ ресурса и может содержать одну/один или несколько строк текста или элементов кодированных данных, по одной/м для каждой версии на том или ином языке. Не обязательно обеспечивать ресурсы на всех языках. Приложение хоста само решает, версия на каком языке наиболее подходит для его нужд.
| Ке$оигсе | ||
| Поле | Тип | Описание |
| М | Строка А8СП | ЦК.! (обычно ϋΚΝ, относящийся к М расширения объекта управления, который содержит кодовый модуль с процедурой, выполняющейся в данный момент) |
| Туре | Строка А8СП | ΜΙΜΕ-тип данных ресурса, описанный в ΙΕΤΡ КГС 2046 |
| Оа!а | Список ЕосаНгедОаи | Список всех различных версий ресурса» для разных местных сред |
| ЬосаНгебПаш | ||
| Поле | Тип | Описание |
| Ьап§иа£е | Строка А8СП | Код языка, указанный в ΙΕΤΡ КГС 3066 |
| Оа!а | Тип зависит от указанного типа типе | Фактические данные для ресурса (текст и т.д.) |
Ресурсы сопровождают программы управления, будучи включены в качестве расширений в объект управления. И ресурса отображается в И внутреннего расширения объекта управления, который содержит кодовый модуль с процедурой, выполняющейся в данный момент.
С целью вычисления канонической последовательности байтов для объектов Кекоигсе, в одном варианте осуществления предусмотрено следующее описание структуры данных:
9.5.1. Простой текст.
Простой текст указан как ΜIΜЕ-тип Чех!'.
9.5.2. Шаблоны текста.
Помимо стандартных текстовых ресурсов в одном варианте осуществления задан тип «шаблон текста». ΜIΜЕ-тип для него: Чех!/уп6.ш!ег!гик!.ос!орик-!ех!-!етр1а!е'.
В одном варианте осуществления шаблон текста содержит символы текста, кодированные в ИТЕ-8, а также именованные заполнители, которые заменяются текстовыми значениями, полученными из параметров, возвращенных в списке параметров, например, для Ех!еп6е68!а!икВ1оск. Синтаксис для заполнителя: '\РЬЛСЕНОЬПЕВ\', где РЬЛСЕНОЬПЕВ задает имя блока параметра и необязательное указание по форматированию. В одном варианте осуществления, процессор шаблонов должен заменять весь жетон '\РЬЛСЕНОЬПЕВ\' форматированным представлением поля Уа1ие этого блока параметра, и форматирование данных Уа1ие указано ниже в разделе 4.2.1.
- 76 012918
В одном варианте осуществления, если символ '\' появляется в тексте вне заполнителя, он должен кодироваться как '\\', и процессор шаблонов, встретив в тексте '\\' всегда будет превращать его обратно в '\'.
Синтаксис для заполнителя: ΤΟΚΜΑΤ|ΝΑΜΕ, где ΝΑΜΕ это имя блока параметра, и ЕОКМАТ это указание по форматированию для преобразования данных параметра в текст. Если правил форматирования, принятые по умолчанию, для типа данных значения параметра достаточно, то указание по форматированию можно исключить, и заполнитель будет просто ΝΑΜΕ.
9.5.2.1. Форматирование.
9.5.2.1.1. Форматирование по умолчанию.
В одном варианте осуществления, правила форматирования, принятые по умолчанию, для разных типов значения таковы:
| Тип | Форматирование |
| 1п(е§ег | Текстовое представление целочисленного значения как знакового десятеричного числа. Текст состоит только из символов цифр от “0” до “9” и символа Если значение равно 0, текст представляет собой строку “0”. Если значение не равно 0, текст не начинается с символа “0”. Если значение отрицательно, текст начинается с символа Если значение положительно, текст начинается с символа ненулевой цифры. |
| К.еа1 | Текстовое представление значения с плавающей точкой в десятичном исчислении. Целая часть значения представлена с использованием тех же правил, которые используются для целочисленных значений. Десятичный разделитель представлен предпочтительным десятичным разделителем |
| приложения хоста. Дробная часть значения состоит из символов “0” в количестве до 6, после которых следует до 3 символов ненулевых цифр. | |
| 8ίηη§ | Собственно значение строки |
| Оа1е | Представление даты, воспринимаемое человеком, согласно предпочтительному для хоста текстовому представлению дат |
| РагатеСег | Текст “<пате>=<уа1ие>”, где <пате> это имя параметра, и <уа!ие> это значение параметра, форматированное согласно правилам форматирования, принятым по умолчанию для этого типа. |
| Ех1епбебРагате1ег | Такое же, как для Рагате1ег |
| Кезоигсе | Текстовая строка данных ресурса. В одном варианте осуществления, ресурс, указанный заполнителем, должен иметь ΜΙΜΙ-ΤΗΠ, который основан на тексте (например, 1ех1 или 1ех(/уп<1. !п1ег(1и51.ос1ориз-(ех1-1етр1а1е). |
| Уа1иеЬ!з1 | Текст “<уа!ие>, <уа!ие>, причем все значения в списке форматированы согласно правилам форматирования, принятым по умолчанию для их типа. |
9.5.2.1.2. Явное форматирование.
Явные имена форматов можно использовать в качестве части ΕΟΚΜΑΤ тега заполнителя. Если встречается неизвестное имя формата, механизм обработки шаблонов использует правила форматирования, принятые по умолчанию.
- 77 012918
| Имя | Форматирование |
| Нех | Шестнадцатеричное представление целочисленного значения, интерпретируемого как беззнаковое. В одном варианте осуществления, это указание по форматированию следует игнорировать для типов данных, которые не являются целыми числами. |
9.6. Объекты «контекст».
В одном варианте осуществления, когда процедура управления выполняется, она обращается к ряду объектов «контекст» с использованием системного вызова 8у51ет.Но51.Се1ОЬ)ес1.
9.6.1. Общий контекст.
В одном варианте осуществления для выполняющихся объектов управления присутствует следующий контекст.
| Имя | Тип | Описания |
| 0сбориз/Регзопа111:у/1с1 | Строка | Ю текущего узла |
| индивидуальности | ||
| 0сСориз/Регзопа111;у/АЬЪгд.Ьи£ез | Контейнер | Атрибуты |
| атрибутов | текущего узла |
индивидуальности
9.6.2. Контекст среды выполнения.
В одном варианте осуществления следующий контекст присутствует для всех объектов управления, которые выполняются на νΜ, созданной с использованием системного вызова 8у8ΐет.Нο8ΐ.8ра^иVт. В одном варианте осуществления, этот контекст не должен существовать или должен быть пустым контейнером для объектов управления, которые выполняются на νΜ, не созданной с использованием 8ук1ет.Но51.8ра\\'1^т.
Имя Тип Описание
ОсЕориз/Кипб!
Идентичность,
Контейнер безымянных
«строка»
выполняется вызывающая сущность системного вызова
9.6.3. Контекст объекта управления.
В одном варианте осуществления, всякий раз, когда выполняется процедура объекта управления, присутствует следующий контекст:
Имя Тип Описание
0сбори5/Сопбго1/1б Строка 16 выполняющегося объекта управления
Осбориз/СопИгоР/АбСгз-ЬиНез Контейнер Атрибуты выполняющегося объекта управления. Этот объект можно опустить, если объект управления не имеет атрибутов.
- 78 012918
9.6.4. Контекст объекта «контроллер».
В одном варианте осуществления, всякий раз, когда выполняется процедура объекта управления, и объект управления указан объектом «контроллер» (например, при обращении к объекту СоШегИКеу для потребления защищенного контента), присутствует следующий контекст.___________
Имя
Тип
Описание
0с£орц5/Соп1:го11ег/1с1
Строка
Ιά контроллера, который указывает на выполняющийся в данный момент объект управления
ОсСориз/СопкгоИег/АббгхЬиДез Контейнер
Атрибуты контроллера, указывающего на выполняющийся данный момент объект управления.
Этот объект можно опустить, если контроллер не имеет атрибутов.
Согласно вариантам осуществления, когда приложению хоста разрешено только группировать ключи контента, которыми управляет единый объект «контроллер», для данного действия, применим лишь один объект «контроллер».
9.6.5. Контекст действия.
В одном варианте осуществления, следующий контекст присутствует всякий раз, когда объект управления вызывается с целью управления действием.
Тип
Имя
Описание
Ос^ориз/АсМоп/Рагате^егз Контейнер Массив пар имя/значение, представляющих параметры, относящиеся к текущему действию, если они существуют. В одном варианте осуществления, каждый тип действия определяет список необязательных и обязательных параметров.
Этот контейнер можно опустить, если действие не имеет параметров.
9.6.6. Контекст объекта «связь».
В одном варианте осуществления, следующий контекст присутствует всякий раз, когда объект управления вызывается с целью ограничения действительности объекта «связь» (например, объекта управления, внедренного в объект «связь»):
Имя
Тил
Описание
0с£ориз/Ыпк/1с1
Строка
Ιά объекта «связь»
ОсСориз/Ыпк/АСбгхЬиЪез Контейнер Атрибуты объекта который содержит выполняющийся объект управления. Этот объект можно опустить, если связь не имеет атрибутов.
- 79 012918
9.6.7. Контекст агента.
В одном варианте осуществления, следующий контекст присутствует, когда выполняется процедура агента объекта управления:
Имя Тип Описание
ОсЬориз/АдепТ/Рагатебегз Контейнер Массив пар имя/значение параметра, представляющих входные параметры агента.
ОсТориз/АдепЕ/Зеззхоп/СопЬехЫЦ Строка Идентификатор контекста сеанса, в котором выполняется агент.
Контейнеры Рагате(ег и §е881оп обычно используются для того, чтобы протоколы, которые требуют от одной сущности передать агент на другую сущность и запустить его там, могли указать, какие входные параметры передать агенту и какие объекты «контекст сеанса» нужно установить хосту при определенных условиях. Наличие или отсутствие определенных объектов «контекст сеанса» позволяет агентскому коду решить, выполняется ли он как часть протокола, который он призван поддерживать, или же он выполняется вне контекста, в каковом случае он может отказаться выполняться. Например, агент, целью которого является создание объекта «состояние» на хосте, на котором он выполняется, может отказаться выполняться, пока он не будет выполняться в ходе конкретного взаимодействия протоколов.
9.7. Действия.
В одном варианте осуществления, каждое действие имеет имя и список параметров. В одном варианте осуществления, некоторые параметры являются обязательными - приложение должно предоставить их при осуществлении этого действия - и некоторые являются необязательными - приложение может предоставить их, а может и опустить.
В одном варианте осуществления заданы следующие стандартные действия.
9.7.1. Воспроизведение.
Описание. Нормальное воспроизведение мультимедийного контента.
9.7.2. Перенос.
Описание. Перенос на совместимую конечную систему.
Перенос на совместимую конечную систему используется, когда контент нужно сделать доступным системе с той же технологией ΌΚΜ, чтобы конечная система могла использовать такую же лицензию, как та, которая содержит этот объект управления, но может понадобиться изменить информацию состояния на источнике, приемнике или на обеих системах. Система, с которой осуществляется перенос, называется источником. Конечная система, на которую осуществляется перенос, называется приемником.
Это действие предназначено для использования совместно с протоколом обслуживания, который позволяет переносить агент из источника на приемник для выполнения необходимых обновлений в сохраняемых состояниях источника и приемника (например, объектов в описанной здесь базе данных состояний). В одном варианте осуществления, объект управления использует с этой целью обязательство КцпАдепЮпРеег. Дополнительная информация об иллюстративных вариантах осуществления этого протокола обслуживания предоставлена ниже в связи с рассмотрением базы данных состояний.
Параметры:
| Имя | Тип | Описание |
| 8шк/И | 81гшд | 14 узла приемника |
| 8тк/А11пЬи1ез | Соп1а1пег | Атрибуты узла приемника. Этот контейнер можно опустить, если узел не имеет атрибутов. |
| ТгапзГегМоде | 81пп§ | ТгапЦ'ег Мо4е ГО, указывающий, в каком режиме переносится контент. Этот ГО может указывать |
- 80 012918 стандартный режим, определенный ниже, или ΟΚΝ для собственного режима системы.
В одном варианте осуществления, заданы следующие
стандартные режимы:
| ГО | Описание | ||
| В.епс1ег | Приемник принимает контент с целью представления | ||
| Сору | Приемник принимает копию контента | ||
| Μονβ | Контент переносится на приемник | ||
| СЬескОш | Контент переносится на приемник с блокировкой. Этот режим аналогичен Моуе с той лишь разницей, что результирующее состояние на приемнике может препятствовать любым другим переносам, кроме переноса обратно на источник. | ||
| Целочисленное значение указывающее, сколько экземпляров счетчиков состояния, связанных с этим объектом управления, нужно перенести на приемник. В одном варианте осуществления, этот параметр является необязательным. Если он отсутствует, переносится только один экземпляр. Он не доложен присутствовать в режимах переноса Кепбег или Сору. |
9.7.3. Экспорт.
Описание. Экспорт в стороннюю конечную систему.
Экспорт в стороннюю конечную систему это действие, которое используется, когда контент нужно экспортировать в кук1еш. где нельзя использовать исходную лицензию контента. Это может быть система с другой технологией ΌΒΜ, система без технологии ΌΒΜ или система с той же технологией, но в условиях, когда требуется лицензия, отличная от исходной лицензии. Система, из которой осуществляется перенос, называется источником. Конечная система, на которую осуществляется перенос, называется приемником.
В одном варианте осуществления, в результате Е.хЮпбеб 81а1ик для методов ОекспЬе, Скеск и РегЕогт этого действия, должен быть задан следующий парметр:
Имя Тип Описание
ЕхрогЕ1пЕо любой Информация, имеющая значение при экспорте контента в конечную систему, указанную в параметрах действия. Фактические тип и контент этой информации зависят от конкретной конечной системы. Например, для систем на основе СС1, она будет содержать биты СС1, задаваемые для экспортируемого контента.
- 81 012918
Параметры:
| Имя | Тип | Описание | |
| Таг{ге18уя1ет | 8ΐπη§ | 8у.ч1ет ГО сторонней системы, в которую производится экспорт. Этот ГО является υΚΝ. | |
| ЕхрогГМоде | 8ίπη§ | ЕхроН Моде ПЭ, указывающий, в каком режиме экспортируется контент. Этот ГО может указывать стандартный режим, определенный ниже, или υΚΝ для собственного режима системы. В одном варианте осуществления заданы следующие стандартные режимы: | |
| ГО | Описание | ||
| ϋοηίΚηολν | Вызывающая сущность не знает предназначенного режима приемника. В этом случае, программа управления должна предполагать, что приемник может допускать любые разрешенные режимы для Таг§е18уз(ет, и должна указывать любое ограничение в состоянии возврата процедур действие. Например, для системы на основе СС1, программа управления может возвращать биты СС1, которые разрешают эквивалент Кепдег или Сору в зависимости от того, что разрешает лицензия. | ||
| Кепдег | Приемник принимает контент с целью представления, и не оставляет используемую копию контента, кроме как в целях кэширования, что указывает каждая конечная система | ||
| Сору | Приемник принимает копию контента | ||
| Μονέ | Контент переносится на приемник |
Конкретные конечные системы могут требовать других входных параметров.
9.7.3.1. Стандартные конечные системы.
9.7.3.1.1. Аудио-СО или ΌνΟ.
В одном варианте осуществления используется стандартный Тагдс18у81ст ΙΌ 'С1сапсх1РстАийю', когда конечная система является незашифровванным носителем, на который записан несжатый аудиосигнал ИКМ, например, записываемый аудио-СО или ΌΥΟ. Для этой конечной системы, параметр ЕхрогПпГо является единичным целочисленным параметром, представляющим флаг авторских прав. Этот флаг задается в младшем бите целочисленного значения.
| Битовый индекс | Описание |
| 0 (Ь5В) | При задании этого флага, бит или флаг СоругтдЫ: должен быть задан в формате записываемого аудиосигнала, если формат поддерживает передачу такого бита или флага. |
10. База данных состояний.
Ниже описано защищенное хранилище объектов, которое механизм ΌΚΜ, согласно предпочтительным вариантам осуществления, может использовать для обеспечения механизма защищенного хранилища состояний. Такое приспособление полезно для обеспечения программ управления, способных считывать и записывать в защищенную базу данных состояний, которая сохраняет от вызова к вызову. Такую базу данных состояний можно использовать для сохранения объектов состояния, например счетчиков
- 82 012918 воспроизведения, даты первого использования, совокупного времени представления и/или т. п. В предпочтительном варианте осуществления защищенная база данных реализована в энергонезависимой памяти, например, флэш-памяти на портативном устройстве, или зашифрованной области жесткого диска на ПК. Однако очевидно, что защищенную базу данных можно реализовать на любом подходящем носителе.
Термин объект, используемый в этом разделе, в целом относится к объектам данных, содержащимся в защищенном хранилище объектов, но не к объектам (например, объектам управления, контроллерам, связям и т.д.), рассматриваемым здесь в других местах; при необходимости провести различие между этими двумя категориями объектов, термин ΌΚΜ объект будет использоваться в отношении объектов, описанных здесь в другом месте (т.е. объектов управления, контроллеров, протекторов, ключей контента, связей, узлов, и т.п.), тогда как термин объект состояния будет использоваться в отношении объектов, хранящихся в базе данных состояний. В нижеследующем рассмотрении, мы будем описывать иллюстративную реализацию базы данных состояний, именуемую 8еакйе11, которая используется в связи с вариантом осуществления механизма ΌΚΜ Ос1орик, описанным здесь в другом месте. Однако очевидно, что варианты осуществления описанных здесь систем и способов можно осуществлять на практике без некоторых или всех признаков этой иллюстративной реализации.
10.1. Объекты базы данных.
Хранилище объектов (например, база данных) содержит объекты данных. В одном варианте осуществления, объекты организованы в логическую иерархию, где объекты «контейнер» являются родителями по отношению к содержащимся в них дочерним объектам. В одном варианте осуществления, существует четыре типа объектов: строка, целое число, массив байтов, и контейнер. С каждым объектом связаны метаданные и тип. В зависимости от типа, объект также может иметь значение.
В одном варианте осуществления программы виртуальной машины могут обращаться к объектам состояния с использованием системных вызовов 8ук1ет.Нок1.Се(ОЬ]ес1 и 8ук1ет.Нок1.8еЮЬ_)ес1, и, как описано более подробно ниже, к метаданным объекта можно обращаться с использованием виртуальных имен. В одном варианте осуществления клиенты базы данных могут изменять некоторые поля метаданных (т.е. они являются доступными для чтения/записи (К^)), тогда как другие поля метаданных доступны только для чтения (КО).
В одном варианте осуществления заданы поля метаданных, представленные нижеследующей таблице:
Поле
Тип
Доступность
Описание
Иаше
Строка
КО
Имя объекта одном варианте осуществления качестве имен объектов разрешены только следующие символы (все остальные зарезервированы) а-ζ.
Α-Ζ,
0-9,
Онпег
Строка
КИ х-ы г
Ιά владельца этого объекта
СгеаРтопОабе
Беззнаковое
КО
Время создания
32-битовое объекта, целое выраженное числом минут, прошедших с
00:00:00 местного времени 1 января
1970 г.
- 83 012918
Мос11£1саЪ1опОа1е Беззнаковое
32-битовое целое
ЕхрдгаЫопОабе Беззнаковое
32-битовое целое
Пада 32-битовое битовое поле
КО Время последнего изменения объекта, выраженное числом минут, прошедших с 00:00:00 местного времени 1 января 1970 г.
Для объектов «контейнер», это время, когда дочерний объект был последний раз добавлен или удален из контейнера. Для других объектов, это время, когда в последний рйэ было изменено их значение.
КИ Время истечения срока действия объекта, выраженное числом минут, прошедших с 00:00:00 местного времени 1 января 1970 г. Значение 0 указывает, что объект не имеет срока действия.
КИ Набор логических флагов, указывающих свойства объекта.
В одном варианте осуществления, задается флаг метаданных, представленный в нижеследующей таблице: __________________________________________________________________________________
Битовый Имя Описание индекс (ЬЗВ) РивЪ1С_КЕА0 Если задан, указывает, что управление доступом для этого объекта таково, что любой клиент может читать объект и его метаданные.
Как указано выше, в одном варианте осуществления существует четыре типа объектов состояния: строки, целые числа, массивы байтов и контейнеры. В этом варианте осуществления, значение объекта «строка» является строкой символов в кодировке иТЕ-8, значение объекта «целое число» является 32битовым целочисленным значением, и значение объекта «массив байтов» является массивом байтов. В
- 84 012918 этом варианте осуществления объект «контейнер» содержит ноль или более объектов. Объект «контейнер» является родительским по отношению к объектам, которые он содержит. Содержащиеся объекты являются дочерними объектами контейнера. Все объекты «контейнер», образующие цепь из родителя объекта, родителя и т.д., называются предками объекта. Если объект имеет другой объект своим родителем, этот объект называется потомком объекта-предка.
10.2. Время жизни объекта.
В одном варианте осуществления, время жизни объектов в базе данных состояний подчиняется ряду правил. Объекты можно уничтожать явно или неявно. Объекты также можно уничтожать в порядке очистки базы данных от мусора. Независимо от того, как уничтожается объект, в одном варианте осуществления применяются следующие правила:
МобЖсаНопЭа!® для родительского контейнера этого объекта задается равной текущему местному времени.
Если объект является контейнером, все его дети уничтожаются при уничтожении объекта.
10.2.1. Явное уничтожение объека.
Явное уничтожение объекта происходит, когда клиент базы данных запрашивает удаление объекта (см. «Доступ к объекту» на предмет подробностей относительно того, как это можно сделать с использованием системного вызова Но51.8еЮЬ)ес1).
10.2.2. Неявное уничтожение объекта.
Неявное уничтожение объекта происходит, когда объект уничтожается в результате уничтожения одного из его объектов-предков.
10.2.3. Очистка от мусора.
В одном варианте осуществления, база данных состояний уничтожает любой объект, срок действия которого истек. Считается, что срок действия объекта истек, когда местное время системы, в которой реализована база данных, превышает значение поля Ехр1га11опОа1е метаданных объекта. Реализация может периодически сканировать базу данных на предмет объектов, срок действия которых истек, и уничтожать их, или может ждать обращения к объекту, чтобы проверить дату окончания его срока действия. В одном варианте осуществления, реализация не должна возвращать клиенту объект, срок действия которого истек. В одном варианте осуществления, при уничтожении объекта «контейнер» (например, вследствие истечения его срока действия), его дочерние объекты также уничтожаются (и все их потомки, рекурсивно), даже если они еще действительны.
10.3. Доступ к объекту.
В одном варианте осуществления, программы виртуальной машины могут обращаться к объектам в базе данных состояний посредством пары системных вызовов: 8у51ет.Но51.Се1ОЬ)ес1 для считывания значения объекта, и 8у51ет.Но51.8е1ОЬ)ес1 для создания, уничтожения, или задания значения объекта.
В одном варианте осуществления, чтобы выглядеть как дерево объектов хоста, база данных состояний монтируется под определенным именем в дереве объектов хоста. Таким образом, база данных выглядит как поддерево в более общем дереве объектов хоста. С этой целью в одном варианте осуществления, база данных состояний содержит встроенный корневой объект «контейнер» высшего уровня, который существует всегда. Этот корневой контейнер, по существу, является именем базы данных.
Все остальные объекты в базе данных являются потомками корневого контейнера. Множественные базы данных состояний можно смонтировать в разных местах дерева объектов хоста (для двух баз данных, монтируемых под одним и тем же контейнером хоста, они должны иметь разные имена своего корневого контейнера). Например, если база данных состояний, корневой контейнер которой имеет имя Эа1аЬа8е1, содержит единственный дочерний объект «целое число» по имени СЫ161, базу данных можно смонтировать под объектом «контейнер» хоста /8еа8йе11, в каковом случае объект СЫ161 будет виден как /8еа811е11/Оа1аЬа5е1/С1н161. В одном варианте осуществления, доступ к объектам в базе данных состояний регламентирует политика доступа.
10.3.1. Чтение объектов.
Значение объекта можно читать с использованием системного вызова 8у51ет.Но51.Се1ОЬ)ес1. В одном варианте осуществления базы данных состояний, четыре типа объекта (целое число, строка, массив байтов и контейнер), которые могут существовать в базе данных, отображаются непосредственно на свои эквиваленты в виртуальной машине. К значениям объектов можно обращаться обычным путем, и можно реализовать стандартные виртуальные имена.
10.3.2. Создание объектов.
Объекты можно создавать, вызывая 8у51ет.Но51.8е1ОЬ)ес1 для имени объекта, который еще не существует. Создание объекта осуществляется согласно спецификации системного вызова. В одном варианте осуществления при создании объекта база данных состояний делает следующее:
Задает поле о\упег метаданных объекта равным значению поля о\упег метаданных родительского объекта «контейнер».
Задает поле Сгеа6опОа1е метаданных равным текущему местному времени.
Задает поле Мо6К1саИопОа1£ метаданных равным текущему местному времени.
Задает поле Ехрйа1юпОа1е метаданных равным 0 (не имеет срока действия).
- 85 012918
Задает поле Е1адк метаданных равным 0.
Задает поле Моб|Пса11опЭа1е родительского контейнера равным текущему местному времени.
При создании объекта по пути более глубокому, чем существующая иерархия контейнеров, в одном варианте осуществления, база данных состояний неявно создает объекты «контейнер», которые должны существовать для создания пути к создаваемому объекту. В одном варианте осуществления, неявное создание объектов «контейнер» подчиняется тем же правилам, что и явное создание. Например, если существует контейнер А, не имеющий детей, запрос на задание А/В/С/8отеОЬ)ес1 приведет к неявному созданию контейнеров А/В и А/В/С до создания А/В/С/8отеОЬ)ес1.
10.3.3. Запись объектов.
Значение объекта можно изменять путем вызова 5>у81ет.Но81.5>е1ОЬ)ес1 для объекта, который уже существует. Если указанный ОЬ)ес1Туре не совпадает с ГО типа существующего объекта, возвращается ЕККОК_ЕЫУАЬГО_РАКАМЕТЕК. В одном варианте осуществления, если ГО типа равен ОВДЕСТ-ТУРЕ-СОМТАГЖК, не нужно указывать никакого значения (ОЬ|ес1Аббге88 должен быть ненулевым, но его значение будет игнорироваться). При задании существующего объекта, база данных состояний задает МобШса11опОа1е объекта равным текущему местному времени.
10.3.4. Уничтожение объектов.
Объекты можно явно уничтожать путем вызова 5>у81ет.Но81.5>е1ОЬ)ес1 для объекта, который уже существует, со значеним ОЬ|ес1Аббге88 равным 0. При уничтожении объекта, база данных состояний предпочтительно задает МобШсайопПа1е родительского контейнера равным текущему местному времени; уничтожает все его дочерние объекты, если уничтожаемый объект является контейнером.
10.3.5. Метаданные объекта
В одном варианте осуществления, к метаданным для объектов базы данных состояний обращаются с использованием системных вызовов 8у81ет.Но81.Се1ОЬ)ес1 и 8у81ет.Но81.8е1ОЬ)ес1 с виртуальными именами. В нижеследующей таблице приведены стандартные и расширенные виртуальные имена, которые могут иметь объекты в одном варианте осуществления базы данных состояний, и указано, как они могут отображаться в поля метаданных.
Виртуальное имя Тип Описание @Цате Строка @Омпег Строка
Поле Ыате метаданных объекта
Поле Оипег метаданных объекта
ЭСгеаВтопОаСе
32-битовое
Поле СгеаМопРабе метаданных беззнаковое объекта целое @МосИ£1саВ1Оп0аВе 32-битовое беззнаковое
Поле Моб1£1саВ1ОпРа£е метаданных объекта целое
ЗЕхрагаВхопРаВе 32-битовое беззнаковое
Поле ЕхртгаВхопРаВе метаданных объекта целое @Е1адз
32-битовое
Поле
метаданных
поле объекта
В одном варианте осуществления, реализация должна отклонять запрос на установление поля Е1адк метаданных, если один или несколько неопределенных флагов заданы равными 1. В этом случае возвращаемое значение для 5>у81ет.Но81.5>е1ОЬ)ес1 равно ЕКК.ОК_ГЫУАЬГО_РАКАМЕТЕК. В одном варианте осуществления при чтении поля Е1адк метаданных, клиент должен игнорировать любой флаг, который заранее не задан, и при задании поля Екщк объекта, клиент должен сначала прочитать его существующее значение и сохранить значение любого флага, который заранее не задан (например, в спецификации системы).
10.4. Управление правами собственности и доступом к объектам.
В одном варианте осуществления, всякий раз, когда делается запрос на чтение, запись, создание или уничтожение объекта, реализация базы данных состояний сначала проверяет, имеет ли вызывающая сущность разрешение на осуществление запроса. Политика, которая регламентирует доступ к объектам, основана на концепциях идентичностей и делегирования принципалов. Для реализации политики, доверенная модель, согласно которой действует реализация, должна поддерживать систему обозначений ау
- 86 012918 тентифицированных программ управления. Для этого виртуальная машина обычно имеет кодовый модуль, который содержит программу, снабжаемую цифровой подписью (прямо или косвенно через защищенную ссылку) с помощью секретного ключа пары ключей РК1, и имеет сертификат имени, который связывает имя принципала с ключом подписания; однако, очевидно, что возможны разные способы определения идентичностей программ управления, любой возможный из которых можно использовать.
В одном варианте осуществления, политика доступа к объектам в базе данных состояний состоит из нескольких простых правил:
доступ для чтения значения объекта предоставляется, если идентичность вызывающей сущности совпадает с владельцем объекта, или если флаг РиВЫС_ЯЕАП задан в поле метаданных Иадк объекта;
доступ для чтения значения объекта предоставляется, если вызывающая сущность имеет доступ для чтения родительского контейнера объекта;
доступ для записи значения объекта предоставляется, если вызывающая сущность имеет доступ для записи в родительский контейнер объекта;
доступ для создания или уничтожения объекта предоставляется, если вызывающая сущность имеет доступ для чтения родительского контейнера объекта;
доступ для чтения или записи метаданных объекта (с использованием виртуальных имен) подчиняется той же политике, что и доступ для чтения и записи значения объекта, с дополнительным ограничением, состоящим в том, что в поля, предназначенные только для чтения, нельзя производить запись.
В одном варианте осуществления, когда политика доступа отклоняет запрос клиента, возвращаемое значение системного вызова для запроса равно ЕЯКОЯ_РЕЯМ188Ю^ПЕМЕП.
Корневой контейнер базы данных состояний, предпочтительно, фиксируется при создании базы данных. При создании объекта, значение его поля О\\гпег метаданных задается равным тому же значению, которое имеет поле О\\пег метаданных его родительского контейнера. Право собственности объекта может изменяться. Для изменения права собственности объекта, значение поля О\\гпег метаданных можно задать путем вызова системного вызова 8у51ет.Но51.8еЮЬ)ес1 для виртуального имени '@О^пег' этого объекта, при условии, что это разрешено правилами управления доступом.
Согласно вариантам осуществления, где программа управления не имеет доступа к объектам, которые не находятся в собственности того же принципала, от имени которого она выполняется, программа управления должна делегировать сторонним объекта доступ к программам, загружаемым из кодовых модулей, которые имеют способность выполняться от имени владельца стороннего объекта. Для этого, программа управления может использовать системные вызовы 8у51ет.Но51:.8ратепУт, 8у§1ет.Но51.Са11Ут и 8у51ет.Но51.Ре1еа5еУт в виртуальной машине управления.
10.5. Протокол передачи лицензии.
Хранение информации состояния в базе данных, например, вышеописанной, позволяет передавать права между устройствами или экспортировать их из домена (например, путем переноса информации состояния на другое устройство). Нижеследующий раздел описывает варианты осуществления протоколов, посредством которых состояние базы данных можно переносить от источника к приемнику. Заметим, что, хотя этот процесс будет относиться к протоколу передачи лицензии, переносится именно состояние базы данных состояний, а не только фактическая лицензия (например, объект управления и т.д.). Протокол называется протоколом передачи лицензии потому, что, в одном варианте осуществления, перенос инициируется выполнением действия «перенос» в программе управления, и потому, что перенос информации состояния позволяет приемнику успешно применять соответствующую лицензию к фрагменту контента.
На фиг. 32 показан пример передачи 3200 лицензии, состоящей из трех сообщений 3202, 3204, 3206. В примере показанный на фиг. 32 приемник 3210 инициирует протокол, направляя запрос 3202 источнику 3212. В одном варианте осуществления, запрос 3202 содержит ΙΌ фрагмента контента, подлежащего переносу. Источник 3212 передает ответ 3204 на приемник 3210, содержащий (ί) агент, который будет задавать состояние в базе данных состояний приемника 3210, а также (ίί) объект(ы) СойепЖеу, нацеленный(е) на приемник 3210. Согласно фиг. 32, приемник 3210 передает на источник 3212 подтверждение 3206, что агент запущен. Получив Ключ(и) контента и/или фрагмент контента, приемник может затем использовать контент (например, воспроизводить его через громкоговорители, отображать его на экране и/или представлять его каким-то иным образом) в соответствии со связанными с ним объектами управления.
Хотя в некоторых вариантах осуществления можно использовать подход, показанный на фиг. 32, некоторые потенциальные проблемы включают в себя следующее.
Нет возможности превентивно сообщить источнику, что представление закончилось. В одном варианте осуществления, протокол, показанный на фиг. 32, поддерживает два режима, в которых возникают проблемы: (ί) Яеп6ег (представление не останавливается), и (ίί) СНескоШ (нет регистрации). Ввиду этой проблемы, сущности, выполняющие объект управления, могут придти к выдаче таймаутов на переносимых состояниях. Однако это может приводить к неудобствам для потребителя, когда, например, пользователь намеревается представить контент на одном устройстве, но решает, что на самом деле он хочет представить этот контент на другом устройстве: при существующей конструкции, ему, скорее всего,
- 87 012918 придется ждать, пока весь фрагмент контента не будет представлен на первом устройстве, прежде чем он может представить его на другом устройстве. Это может быть нежелательным, если контент сравнительно долог (например, является фильмом).
Может быть трудно анализировать лицензию, связанную с Соп1еп1 ГО в запросе. В одном варианте осуществления, запрос содержит только СоШеЩ ГО, и источник извлекает лицензию, связанную с Соп1еп1 ГО из его базой данных лицензий. Однако этот процесс может быть подвержен ошибкам, поскольку лицензии могут храниться на сменных носителях, и во время применения протокола, конкретная лицензия может отсутствовать, если носитель был удален. Кроме того, даже при наличии лицензии, может быть неудобно осуществлять поиск лицензий в хранилище лицензий. Кроме того, поскольку с набором Соп1еп1 ГО может быть связано несколько лицензий, может быть трудно определить, является ли проанализированная лицензия именно той, которая была предусмотрена в запросе.
Невозможно превентивно запросить у программы управления проверку близости. В одном варианте осуществления, набор системных вызовов/обратных вызовов/обязательств не поддерживает способ, которым программа управления может запрашивать проверку близости равноправного устройства. Вместо этого, программа управления можно только считывать значение объекта хоста Ос1орик/Ас1юп/Ратате1егк/ 81пк/Ргох1т11у/Ьак1РгоЬе, в который приложение в ходе переноса загружает значение, которое оно получило из предыдущего выполнения протокола проверки близости. Это может составлять проблему в случае, когда может быть желательно избегать проверки близости, если такая проверка близости не требуется (например, если известно, что приемник находится в определенном домене).
Протокол имеет только три цикла передачи сообщений. Согласно варианту осуществления показанному на фиг. 32, протокол ограничивается тремя циклами передачи сообщений. Это может быть серьезным ограничением, поскольку протокол будет не способен работать в случае, когда обратный вызов ОпЛдеЩСотр1е1юп возвращает расширенный блок состояний с другим обязательством КипАдепЮпРеет. Кроме того, по окончании протокола, приемник не будет знать наверняка, успешно ли выполнен протокол. Кроме того, проверка близости понадобится до передачи ответа (см. предыдущую проблему), но это не нужно в случае, когда источник и приемник находится в одном и том же домене. Кроме того, в протоколе, показанном на фиг. 32, источник передает ключ контента приемнику, не зная, будет ли когда-либо использоваться этот ключ контента.
Нет возможности указать в Е8В, необходима ли передача лицензии. Согласно варианту осуществления показанному на фиг. 32, когда клиент ΌΗΜ оценивает лицензию (например, Соп1го1.Лс11опк.Р1ау.СЬеск), непросто указать сущности, записывающей объект управления, что передача лицензии необходима для получения состояния, которое позволит успешно оценить объект управления.
Источник не может инициировать перенос. В протоколе, показанном на фиг. 32, передача лицензии инициируется приемником. Желательно, чтобы источник также мог инициировать перенос.
Усовершенствованные варианты осуществления
Варианты осуществления, описанные ниже, могут разрешать или смягчать некоторые или все вышеописанные проблемы.
Решение проблемы освобождения. В одном варианте осуществления предусмотрена новая операция освобождения. Когда эта операция указана в запросе, ТгапкГег Ыобе ГО задается равным Ке1еаке. Чтобы клиент осуществлял корреляцию между операциями Кепбег/СЬескОи! и Ке1еаке, в запрос добавляется необязательный элемент 8еккюп1б (см. нижеследующий раздел). В одном варианте осуществления, при наличии этого элемента, это отражается в дереве объектов хоста для контекста действия «перенос» под 8еккюп1б.
Приемник знает, что он отправил этот 8еккюп1б в запросе на освобождение, если расширенный блок состояний, который он получил в сообщении Теагбо\уп (см. ниже) содержит параметр:
Имя параметра: 8еккюп1б;
Тип параметра: 81гшд;
Флаг этого параметра задан равным СКШСЛЬ.
Решение проблемы анализа лицензий (повторного анализа запроса). В одном варианте осуществления решение состоит в том, что устройство-приемник помещает пучок(и) лицензий в запрос, что, по существу, гарантирует, что приемник и источник будут выполнять одну и ту же лицензию. Согласно варианту осуществления, показанному на фиг. 32, схема ХЫЬ для запроса такова:
<хз:сотр1ехТуре пате=1лсепзеТ|,апз&гК.едиез1Рау1оа<1Туре>
<хз:зециепсе>
<хз:е1ешет ге(^Соп1еп11<11лз(7>
<хз:е!етеп1 ге(=Орегайоп/> <хз:е1етеп1 ге£=ос1:Вип<11е/>
</хз:зециепсе>
_________</хз:сотр1ехТуре>____________________________________________________________
Когда СоЩепПбЫк! содержит список Соп1еп1 ГО (по одному на каждый трек/поток), идентифицирующих контент, ОретаЕоп содержит тип операции передачи лицензии и Випб1е содержит узел Регкопа1ϊΐγ запрашивающей сущности и связанную с ним подпись.
Для ухода от вышеописанной проблемы анализа лицензий, пучок(и) лицензий можно включить в
- 88 012918 запрос, например, изменив схему следующим образом:
<! - новые элементы -->
<хз:е!етеп1 пате-ТЛсепзеРаН (уре- 'Ь1сеП5еРаг|Туре/>
<х5:сотр1ехТуре пате—ЧлсепзеРаг1Туре>
<хз:зедиепсе>
<хз:е1етепг ге^ос(:Вшк11е т1пОссигз=’0”/>
</х8:зечиепсе>
<хз:аПпЬше пате=соп1еп11<Г изе=ор(юпаГ'/>
</хз:сотр1ехТуре>
<хз:е1етеп1 пате-’Ысепзе 1уре='Ъ1сепзеТуре> <хз:сотр1ехТуре пате=1лсепзеТуре>
<хз:зе9иепсО <хз:е!етеп1 геР='ТхсепзеРаг1 тах0ссигз=1тЬоип(1е(Г'/>
</хз:зециепсе>
<х5:сотр1ехТуре>
<!- измененный Ь|сепзеТгапзРегКедие5(Рау1оас1Туре --> <хз;еотр1ехТуре пате- 'ЫсспзеТгапзГегкедиез1Рау1оас1Туре''> <хз:5ечиепсе>
<хз:е!етеп( геГ-'Ъ|сепзе/> <!— определение см. выше — >
<хз:е1етеп1 ге(-Орегатюп'7>
<хз:е1ешеп1 геР=ос1:Вин<11е,'/>
<хз:е1етеп( пате-’’8езз1оп1<Г' 1уре=”хз:з1пп(» ттОссигз-’0/>
<хз:е1етеп1 пате-'НссйзСотетКсуз” 1урс=”хз:Ьоо1еап” ттОссигз=”0‘7> </хз:зечиепсе>
________<хз:сотр1ехТуре>__________________________________________________________
В этой схеме, элемент Соп1еп11бЫк1 заменен элементом Ысепке. Этот элемент несет набор элементов ЫсепкеРай. Элемент ЫсепкеРай несет элемент ос1:Випб1е, содержащий объекты «лицензия», а также необязательный атрибут Соп1епИб указывающий, что объекты «лицензия» применяются к этому конкретному СоШепПб. Элемент ЫсепкеРай без атрибута СоШепПб означает, что объекты, содержащиеся в нижележащем пучке, применяются ко всем Соп1еп1 ΙΌ (обычно контроллерам и объектам управления).
В одном варианте осуществления необязательный элемент 8еккюп1б не может присутствовать, за исключением случая, когда операция представляет собой игп:таг1ш:соге:1-2:кеМсе:11сепке4гапкГег:ге1еаке в каковом случае он может присутствовать, если параметр §еккюп1б принят в Расширенном блоке состояний соответствующего действия гепбег или сНескоШ (см. выше).
В одном варианте осуществления, необязательный элемент №ебкСоп1еп!Кеук должен присутствовать со значением «ложь», если приемник знает, что он уже способен дешифровать ключи контента. Отсутствие этого элемента означает, что источник должен перешифровать Ключи контента приемника в случае успеха протокола.
В одном варианте осуществления, при получении такого запроса, элемент лицензии обрабатывается следующим образом:
(1) собирают все атрибуты СоШепПб, найденные в элементах ЫсепкеРай;
(2) обрабатывают все элементы Випб1е, найденные в элементах ЫсепкеРай;
(3) открывают набор СоШепПб, собранных ранее;
(4) проверяют соответствующие подписи соответствующих объектов;
(5) в необязательном порядке, вызывают метод Соп1го1.Асбопк.ТгапкГег.Сйеск на обработанном объекте управления;
(6) вызывают СопйокАсйопк.ТгапкГег.РегГогт на объекте управления процесса.
Разрешение программам управления превентивно запрашивать проверку близости приемника. Чтобы позволить программам управления делать это, можно задать новую пару ОЬйдабопк/СаНЬаскк. В частности, объект управления может поместить обязательство Ргох1тйуСйеск§1пк в свой расширенный блок состояний. Это указывает приложению, что близость к приемнику должна проверяться. Когда проверка близости произведена, приложение производить обратный вызов объекта управления с использованием обратного вызова Оп§1пкРгох1тйуСйескеб.
В одном варианте осуществления, задается обязательство Ргох1тйуСйеск, которое применимо только в контексте передачи лицензии. В этом варианте осуществления, должно существовать нуль или одно такое обязательство на расширенный блок состояний, и, если оно присутствует, также должен присутствовать обратный вызов Оп§шкРгох1тйуСйескеб.
| Имя | Тип | Описание |
| Ргох1ткуСЬеск | Уа1ие1л81 | Приложение хоста должно осуществлять протокол проверки близости к устройству-приемнику. |
| Тип | Описание | |
| 81ПП£ | 1<1 узла индивидуальности, который должен быть проверен на близость |
Обратный вызов Оп§1пкРгох1тйуСйескеб
- 89 012918
| Имя | Тип | Описание | |
| ОпРгох1гш1уСкеске ά | Уа1иеЬ181 | Приложение хоста должно осуществлять обратный вызов по завершении проверки близости в одном из параметров обязательства. | |
| Тип | Описание | ||
| СаИЬаск | Процедура для обратного вызова и соответствующий куки. |
Разрешение множественных циклов передачи сообщений в протоколе. На фиг. 33 показано изменение протокола, которое допускает множественные циклы передачи сообщений. Согласно варианту осуществления, показанному на фиг. 33, сообщение 8е!ир 3302 может, например, быть таким же, как усовершенствованное сообщение запроса на передачу лицензии, описанное выше в связи с проблемой/решением анализа лицензий.
Согласно фиг. 33, после 8е1ир 3302, приложение запускает объект управления, как объяснено выше, и получает Расширенный блок состояний (Έ8Β). Этот Έ8Β может содержать обязательство КипЛдепЮпРеег/обратный вызов ОпАдеп1Сотр1е1юп. В одном варианте осуществления, обязательство ΒииАдеиΐΟиРеег содержит все параметры, которые приложение источника 3312 должно встроить в сообщение КипАдеп1 3304. Заметим, что в одном варианте осуществления, сообщение КипАдеп! 3304 также отправляется, если приложение сталкивается с другой парой обратный вызов/обязательство КипАдепЮпРеег/ОпАдегИ С'отр1е1юп в Расширенном блоке состояний обратного вызова ΟиАдеиΐСотр1еΐ^ои (после одного или нескольких обменов сообщениями ΒииАдеиί/АдеиίΒе8и1ΐ).
В одном варианте осуществления, если Έ8Β не содержит обязательство КипАдепЮпРеег/обратный вызов ΟиАдеиΐСотр1еΐ^ои, это значит, что нужно отправить сообщение Теагбо\уп (см. ниже). Заметим, что этот Έ8Β может содержать обязательство РгохшйуСйеск/обратный вызов О^хпкРгоххтйуСкескеб, в каковом случае осуществляется протокол проверки близости, и результат считывается из Έ8Β проверенного обратного вызова О^шкРтохшйу до отправки сообщения Теагбозтп.
В одном варианте осуществления, полезная нагрузка сообщение КипАдегИ 3304 идентично сообщению Ке^роике, предусмотренного в предыдущей конструкции, за исключением того, что оно не несет СоШейКеуЬШ.
Согласно фиг. 33, после того, как приемник 3310 запустит агент, переданный источником в сообщении КυиАдеиΐ 3304, приемник 3310 передает сообщение Адеп1Ке5и11 3306 на источник 3312. В одном варианте осуществления, полезная нагрузка сообщения такая же, как в сообщении Соиίϊ^таΐ^ои, описанном в связи с фиг. 32.
Согласно фиг. 33, сообщение Теагбозтп 3308 передается приложением-источником 3312, когда расширенный блок состояний обратного вызова ΟиАдеиΐСотр1еΐ^ои не несет никакой пары обратный вызов/обязательство КииАдеиΐΟиРее^/ΟиАдеиΐСотр1еΐ^ои, и это значит, что протокол завершен. В одном варианте осуществления, сообщение Теагбозтп 3308 несет два фрагмента информации: (ί) описание результата протокола, благодаря чему приемник 3310 знает, успешно ли завершился протокол, указание причины неудачи (дополнительные подробности см. ниже), и (п) в случае успеха протокола, обновленные объекты Соп1еп1Кеу (Соп1еп1КеуЫ51 ответа в предыдущем сообщении), если элемент Nееά8СоиΐеиΐКеу сообщения «установка» задан равным «истина» или отсутствует.
В одном варианте осуществления, описание результата протокола фактически представляет собой Расширенный блок состояний (Έ8Β) последнего вызова объекта управления, не несущего никаких пар обязательство/обратный вызов, связанных с агентом.
В случае неудачи, параметры Έ8Β могут указывать на ресурсы. В одном варианте осуществления, эти ресурсы размещены в расширении ВекоигсеЬШ объекта управления, которое отправлено в сообщении 8е1ир.
В случае успеха, в одном варианте осуществления, время жизни кэша указывает, в течение какого времени можно использовать Ключи контента без нового запроса объекта управления.
Пример такого ХМЬ-представления Έ8Β показан ниже и может быть добавлен в схему виртуальной машины:
- 90 012918 <хз:е1етеп( пате=СасЬеОига*юп Гуре-'СасЬеЕ>игаЙопТуре/>
<!-- СасЬеОигаГюпТуре <хз:сотр1ехТуре пате-'СаскеОигапопТуре'1;· <хз:аиНЬг|Ге пате=гуре Еуре”=хз:тГ“> <х5:аипЬи1е пате-Ч-аГие Гуре=х5:тГ”/> </хз:сотр1ехТуре>
<хз:е1етеп1 пате=ЕхГеп<1е<18ГаГизВ1оск'' Гуре-Ехгеп<1е<]81а1изВ1оскТуре/>
<!- ЕхГепке<151аГизВ1оскТуре <Х5 :сотр1ехТуре пате=ЕхГеп<1ес15ГаГизВ1оскТуре>
<хз:5еяиепсе>
<хз:е1етепГ ге!=Сас11еОига1юп/>
<хз:е1етепГ пате-'ТагагпеГегз Гуре=“Уа1иеЬ|зГВ1оскТуре т1пОосиГ5=,'0''/> </х5:зеДиепсе> <х5:а1ГпЬиГе пате-'ё1оЬа1Е1а£з ιγρβ-χ5:ίηΓ ке(аиИ=''О изе-'орйопаГ/> <хз:аГГпЬиГепате=саГе50гу Гуре-'хзкпГ изе_гедшгес1/> <х5:аГГпЬиГе пате=5иЬсаГе£огу 1уре=хз:т1 изе=ор1юпа1/> <хз:аГГпЬиГе пате=1оса1Па£5 Гуре=хз:тГ изс=геяи1ге<)’'Л>
________</хз:сотр!ехТуре>_________________________________________________________________
Ниже приведен пример случая использования представления в соответствии с вариантом осуществления вышеописанных усовершенствованных механизмов передачи лицензии. В этом примере функция импорта вещания импортирует фрагмент контента со следующей лицензией:
Р1ау: ОК, при наличии локального состояния;
ТгапкГег:
Кепбег ОК, если приемник находится в домене X, или если приемник находится поблизости. Единовременно можно представлять только один параллельный поток.
Пусть Соге ^КΜС1^еπΐ1 запрашивает разрешение на представление потока контента. 8е!ир Вес.|иек1 передается от приемника (Соге ^КΜС1^еπΐ1) на источник (функция ВС 1шрой), содержащая следующие параметры:
Ысепке: лицензия, связанная с контентом, который приемник хочет представить;
Орегайоп = игп:1паг1ш:соге:1-0:кегисе:НсепкеТгапкГег:гепбег
Випб1е = Узел индивидуальности приемника.
Получив запрос, приложение-источник наполняет соответствующие объекты хоста и вызывает метод Соп1го1.Ас1юпк.ТгапкГег.РегГопп. Ниже показан иллюстративный псевдокод метода, регламентирующего перенос представления:
/* псевдокод метода, регламентирующего перенос представления */
Е8В* Тгап8(егКепбегРет£огт(Но510Ь)ес1Тгее* I) {
И проверить блокировку
1£Ц->6еЮЬ]есгС‘8еа8Ье11' ../1оск”) !=ΝΙΛΧ) { геШгп ηβνν Е8В(АСТЮТМ2>ЕЪПЕО);
} е!зе { // блокировка, ограниченная по времени, // которую мы снимем в случае неудачи Ь>8еЮ1уес1(“8еа8Ье11/.. .Лоск”, 1);
1->8еЮЬ]ес1(“8еа8ке11/.. .Лоск@Ехр|габопТ|те, Тш1е.Се1Сиггеп1() + 180);
// возвратить Е8В, который содержит обязательство КипАдепЮпРеег
И и обратный вызов ОпАдеп1Сотр1е1еб гешт пелу Е8В(ΑϋΤΙΟΝ_ΟΚΑΝΊΈΟ, ηυνν Ο5Ιί§α6οη(ΚυΝ_ΑσΕΝΤ_ΟΝ_ΡΕΕΚ,
СЙесЮотатАдеп»), ηονν Са11Ьаск(СЖАОЕКТСОМРЕЕТЕО,
КепбегАде п!Со тр1е!еб));
}
Предположим, представление не заблокировано, и выполняется обязательство КипАдепЮпРеег. Сообщение КипАдеп! передается с объектом управления, содержащим метод СЕескОоташАдепГ Получив это сообщение, приемник наполняет соответствующие объекты хоста и вызывает метод СйескЭоташАдепГ Ниже показан иллюстративный псевдокод для ОгескОоташАдегИ:
- 91 012918 /* псевдокод для СЬескОошатАдеп! */
АдетКезиИ* СЬескОота!пА£епг(Ноз10Ь)ес(Тгее* I) {
И проверить, доступен ли узел домена
ΪΓ(ΙδΝο4еКеасЬаЪ1е(“ит:таг1пк...:дотат2042х”}) { гегит печу Адеп(Ке5и1г(5иССЕ85);
} е1зе { гешт печу АдетНКезиЩЕА1ШКЕ);
}
Предположим, в целях этой иллюстрации, что приемник действительно находится в домене. Затем приемник передает сообщение ЛдеШКекиИ, содержащее результат этого агента. Получив ЛдеШКекиИ, источник вызывает метод обратного вызова. Ниже показан иллюстративный псевдокод для КепбегЛдеп1Сотр1е1еб:
/♦ псевдокод для КепбегА«е1йСо1пр1е1еб */
Е5В* КепбегА§еп1Сотр1еге<1(НояОЬ|ес1Тгее* I,
АдегИКезик* аг) {
ίΓ (аг->1зЗиссе55()) {
И дать Е8В без обязательства/обратного вызова // и время жизни кэша геШгп лечу ЕЗВ/ЛСТЮТЧСКАКГЕО, печу СасЬеОига1юп{0));
} е1зе {
Ц попытаться произвести проверку близости геШгп пече Е8В( Α€ΤΙΟΝ_ΟΚΑΝΤΕϋ.
лечу ОЫщаноп(СНЕСК_РК.ОХ1М1ТУ,
Г-ХЗсЮ^ссЦ.. ./ЗшкЛб”), лечу Са11Ьаск(ОН_81МК_РКОХ1М1ТУ_СНЕСКЕО,
Ргох11П1(уС11ескСотр1с1сф);
} }
Мы предположили, что агент успешно проверил принадлежность приемника домену. Сообщение Теагбочч'п передается с (1) перешифрованными ключами контента для приемника (с использованием ключей, снабженными узлом «приемник» в запросе 8е)нр), и (ίί) Е8В, несущим время жизни кэша, указанный выше (0 в этом случае указывает, что приемнику нужно повторно сделать запрос в следующий раз, когда он хочет обратиться к контенту). Когда приемник принимает это сообщение, он знает, что разрешено представлять контент, и имеет необходимые ключи контента.
Теперь предположим, что пользователь хочет представлять контент на другом своем устройстве, ОКМС11еп12. Проблема в том, что контент заблокирован на 180 мин на источнике. К счастью, когда пользователь нажимает 8ТОР на ОКМСйепН, ОКМСИепП инициирует новый протокол передачи лицензии с операцией: Ке1еаке. Получив запрос, приложение-источник наполняет соответствующие объекты хоста и вызывает метод Соп1го1.Лс1юпк.ТгапкГег.РегГогт. Ниже показан иллюстративный псевдокод метода, регламентирующего освобождение переноса:
/* псевдокод метода, регламентирующего освобождение переноса */
Е8В* Тгап8£егКе1еазеРегГопп(Но51О1уесгТгее* I) { // проверить блокировку
И(1->6е10Ь]есК“8еа8йе11/.../1оск”) !=ΝυΐΛ) { Ь>8е1ОЬ)есЦ'‘5еа5ке11/.../1оск, ЬЮЬЬ); // удалить геГит печу Ε8Β(Α€ΤΙΟΝ_6ΚΑΝΤΕΟ), } е!$е { ге!игп печу Ε8Β(ΑεΤΙΟΝ_ΟΕΝΙΕΟ);
} }
Поскольку в Е8В не найдено никакого обязательства/обратного вызова, это означает, что сообщение Теагбочч'п отправляется обратно с этим Е8В.
Таким образом, этот случай использования представления иллюстрирует, что, в определенных вариантах осуществления, нет необходимости запрашивать ОКМСНеп! операции представления на локальную повторную оценку объекта управления, состояние не нужно переносить от источника к приемнику, объект управления может превентивно запрашивать проверку близости, и контент можно освобождать, когда представляющая сущность закончила работать с ним.
11. Сертификаты.
В одном варианте осуществления сертификаты используются для проверки мандата, связанного с криптографическими ключами, до принятия решений на основании цифровой подписи, созданной с помощью этих ключей.
В некоторых вариантах осуществления механизм ΌΗΜ построен так, чтобы быть совместимым со стандартными технологиями сертификатов, и может пользоваться информацией, найденной в элементах таких сертификатов, например, периодах действия, именах и т. п. Помимо этих основных ограничений, в некоторых вариантах осуществления можно задать дополнительные ограничения в отношении того, для чего можно использовать сертифицированный ключ, а для чего его нельзя использовать. Это можно делать, например, с использованием расширений использования ключа, доступных как часть стандартного
- 92 012918 правила кодирования сертификатов. Информация, закодированная в таких расширениях, позволяет механизму ΌΚΜ проверять, авторизован ли ключ, которым подписан конкретный объект, для использования с этой целью. Например, определенный ключ может иметь сертификат, который позволяет ему подписывать объекты «связь» только, если связь идет от узла с конкретным атрибутом к узлу с другим конкретным атрибутом, но не другую связь. Поскольку семантика общей технологии, используемая для выражения сертификата, обычно не способна выражать такое ограничение, поскольку она не располагает средствами для выражения условий, которые относятся к элементам, например, связям и узлам, характерным для механизма ΌΚΜ, в одном варианте осуществления такие ограничения для конкретного механизма ΌΚΜ переносятся как расширение пользования ключом для базового сертификата, которое будет обрабатываться приложениями, которые сконфигурированы для использования механизма ΌΚΜ.
В одном варианте осуществления ограничения в расширении пользования ключом выражаются категорией пользования и программой ограничения νΜ. Категория пользования указывает, объекты каких типов ключ авторизован подписывать. Программа ограничения может выражать динамические условия на основании контекста. В одном варианте осуществления любая проверяющая сущность, получающая запрос на проверку действительности такого сертификата, должна понимать семантику механизма ΌΚΜ, и делегирует оценивание выражения расширения пользования ключом механизму ΌΚΜ, который использует экземпляр виртуальной машины для выполнения программы. Сертификат считается действительным, если результат выполнения этой программы успешен.
В одном варианте осуществления роль программы ограничения состоит в возвращении логического значения. Истина означает, что условия ограничения выполнены, и ложь означает, что они не выполнены. В одном варианте осуществления программа управления обращается к некоторой информации контекста, которую можно использовать для принятия решения, например, информации, доступной программе через интерфейс «объект хоста» виртуальной машины. Информация, доступная в качестве контекста, зависит от того, какого типа решение пытается принять механизм ΌΚΜ, когда он запрашивает проверку сертификата. Например, прежде чем использовать информацию в объекте «связь», в одном варианте осуществления, механизму ΌΚΜ нужно проверить, что сертификат ключа, которым подписан объект, позволяет использовать этот ключ с этой целью. При выполнении программы ограничения, среда виртуальной машины наполняется информацией, относящейся к атрибутам связи, а также атрибутам узлов, на которые ссылается связь.
В одном варианте осуществления программа ограничения, внедренная в расширение пользования ключом, кодируется как кодовый модуль виртуальной машины, который экспортирует по меньшей мере одну точку входа по имени Ос1ори8.СепШса1е.<Са1едогу>.Сйеск, где имя СаЮдогу указывает сертификаты какой категории нужно проверить. Параметры для программы проверки проталкиваются в стек до вызова точки входа. Количество и типы параметров, передаваемых в стек, обычно зависит от категории оцениваемого расширения сертификата.
12. Цифровые подписи.
В предпочтительных вариантах осуществления некоторые или все объекты, используемые механизмом ΌΚΜ, подписываются. Ниже приведено описание, как объекты снабжаются цифровыми подписями в одном варианте осуществления с использованием спецификации цифровой подписи ΧΜΕ (1Шр:/Л\1\1У.\у3.огд/ТЕ/хт1б51д-соге) (ΧΜΕΌδί^). Кроме того, описан метод каноникализации ХЫЬ, совместимый с эксклюзивной каноникализацией ХЫЬ (1Шр://\у\у\у.\у3.огд/ТК./хт1-ехс-с14п/) (с14п-ех), выход которого может обрабатываться анализатором, не знающим пространства имен ΧΜΕ В Приложении Ό представлена дополнительная информация по иллюстративной сериализации объектов, включающую в себя иллюстративный способ вычисления канонической последовательности байтов для объектов, не зависящий от кодировки.
Как показано на фиг. 28, 34 и 35, в предпочтительных вариантах осуществления, определенные элементы в лицензии ΌΚΜ подписываются. Методы, например, показанные на фиг. 28, 34 и 35 полезны для предотвращения или затруднения подделки путем замены компонентов лицензии. Согласно фиг. 34, в предпочтительном варианте осуществления, объект «контроллер» 3402 включает в себя криптографические дайджесты или хэши (или другие подходящие связки) 3405, 3407 объекта Соп1еп(Кеу 3404 и объекта управления 3406, соответственно. Контроллер 3402 сам подписывается с помощью ΜАС (или, предпочтительно, НМАС, который использует ключ контента) и подписи открытым ключом (обычно поставщика контента или лицензии) 3412. В предпочтительном варианте осуществления, подпись открытым ключом контроллера 3412 сама подписывается с помощью НМАС 3410 с использованием ключа контента. Очевидно, что в других вариантах осуществления, можно использовать другие схемы подписи, в зависимости от нужного уровня безопасности и/или других системных требований. Например, можно использовать разные схемы подписи для подписывания контроллера и/или объекта управления, например РК1, стандартных ΜАС и/или т.п. Согласно другому примеру можно вычислять отдельную подпись ΜАС для объекта управления и контроллера, вместо того, чтобы включать дайджест объекта управления в контроллер и вычислять единую подпись ΜАС контроллера. В порядке еще одного примера контроллер можно подписывать как подписью ΜΛί.'. так и подписью открытым ключом. Альтернативно или дополнительно, можно использовать ключи, отличные от вышеописанных, для генерации различных под
- 93 012918 писей. Таким образом, хотя на фиг. 28, 34 и 35 показано несколько преимущественных методов подписания в соответствии с несколькими вариантами осуществления, очевидно, что эти методы являются иллюстративными и неограничительными. На фиг. 35 показан вариант осуществления, в котором контроллер ссылается на множественные ключи контента. Согласно фиг. 35, в одном варианте осуществления, каждый из ключей контента используется для генерации НМАС контроллера и подписи РК!
В одном варианте осуществления режим данных, обработка, входные параметры и выходные для каноникализации ХМЬ такие же, как для эксклюзивного канонического ХМЬ (с14п-ех) за исключением того, что префиксы пространств имен удалены (пространства имен обозначаются с использованием принятого по умолчанию механизма пространства имен) и внешние сущности не поддерживаются, за исключением символьных сущностей. Первое ограничение предусматривает, что атрибут и его элемент должны находиться в одном и том же пространстве имен.
На фиг. 42 показано соотношение между с14п-ех и иллюстративной каноникализацией ХМЬ в одном варианте осуществления, где <хш1> является одной действительной ХМЬ, и где <хш1>' = <хш1> только, если <хш1> не имеет внешних сущностей и префиксов пространств имен.
Ниже приведен простой пример упрощенной схемы подписи: однако, в предпочтительном варианте осуществления, используется стандартная каноникализация ХМЬ.
| оп£|па1 | <п1:е1еш2 ΐΰ=ίοο |
| хп11пз:п0-Тоо:Ьаг хш1п5:п1“ Ъпр://'ехатр1е.пе( хт1п5;пЗ=пр://ехатр1е.ог§> <пЗ:Яий/> <п1:е1ет2> | |
| ргосеззей | <е!ет2 хп11пз=1й1р://ехатр1е.пеГ ΐά=ίοο> <а(и£Г хт1п5=,,йр://ехатр1е.огз/> </е!ет2> |
Элементы подписи, рассмотренные в этом разделе, принадлежат пространству имен ХМЬПЗ1д (х1п1пк=1Шр://\\л\лу.\у3.огд/2000/09/х1пИк18#) и заданы в схеме ХМЬ, заданной в спецификации ХМЬПЗ1д. В одном варианте осуществления, элемент «контейнер» ХМЬ-представления объектов ЭКМ представляет собой элемент <Ви^1е>.
В одном варианте осуществления нужно подписывать следующие объекты:
узлы;
связи;
контроллеры;
Объекты управления (необязательные);
расширения (в зависимости от переносимых ими данных).
В одном варианте осуществления подписи нужно отсоединять и элемент <8|дпа1иге> должен присутствовать в объекте <Ви^1е>, который содержит ХМЬ-представление объектов, которые нужно подписывать.
В одном варианте осуществления блок содержит элемент <8181^[пГо>
элемент <З^диаΐи^еVа1ие>
элемент АКеуШ^
В одном варианте осуществления ^ΐ^εάΣώ^ встроен в следующие элементы:
<Сапошса1|/а1юпМе11ю0> В одном варианте осуществления, элемент <Саиоп^са1^ζаΐ^оиΜеΐйоά> пуст, и его атрибут Л1догйЬш имеет следующее значение: 1Шр://\у\у\у.\у3.огд/2001/10/х1п1-ехс-с14п# ^дпаШгеМеНо^
В одном варианте осуществления элемент <8|дпа1игеМе11ю0> пуст, и его атрибут Л1доп11ип имеет следующие значения:
1Шр://\у\у\у.\у3.огд/2000/09/х1пИк18#111пас-к11а1 (подпись НМАС) 1Шр://\у\у\у.\у3.огд/2000/09/х1пИк1д#гка-к11а1 (подпись открытым ключом) <КеПегепсе> В одном варианте осуществления может существовать один или несколько элементов <КеПегепсе> в блоке сЗщпеШпГоА если более одного объекта нужно подписывать одним и тем же ключом (например, это может иметь место для объекта Соп1го1 и Соп1го11ег).
В одном варианте осуществления при подписывании объекта, значение атрибута 'ЦК!' элемента <КеПегепсе> равно ГО объекта, на который ссылаются. При подписывании локального элемента ХМЬ (например, в случае множественных подписей для метода открытой подписи для объектов СойгоИег), значение ЦК! равно значению атрибута 'Ιά' элемента, на который ссылаются.
В одном варианте осуществления, когда ссылка указывает на объект, который снабжен дайджестом в ссылке, является не ХМЬ-представлением объекта, но его канонической последовательностью байтов. Это преобразование объекта указано в ХМЬОЗщ посредством блока <ТгапПогшк>. Поэтому, в одном варианте осуществления, элемент <КеПегепсе> внедряет этот блок:
- 94 012918 <ГгапГош15>
<ТгапзГогт А1ёог1111т='’11Пр://^тм/.1п1ег1гиз1.сот/осГори5/сЬ5-1_0н/>
<.'Тгап1опп5>
В Приложении Ό представлена дополнительная информация. В одном варианте осуществления никакие другие блоки <ТгапГогт> не разрешены в качестве ссылок на объект.
В одном варианте осуществления элемент ^здекШеШо^ пуст, и его атрибут А1доп11ип имеет следующее значение: 1Шр://\у\у\у.\у3.огд/2000/09/хт1б51д#511а1
Элемент <П1де81Уа1ие> содержит значение дайджеста в кодировке Ьаке64.
<8^диаΐи^еVа1ие> В одном варианте осуществления, значение подпись является значением в кодировке Ьаке64 подписи элемента <8|дпеб1пГо> каноникализированного (ех-с14п) ключом, описанным в элементе <Кеу1п£о>.
<Кеу1пГо>
Случай НЫАС-8НА1 для подписей объектов Соп1го11ег
В одном варианте осуществления в этом случае <Кеу1п£о> имеет только один дочерний элемент: <КеуNате>, который указывает Ш ключа, использованного для подписи НМАС.
Пример:
<Кеу1пГо>
<КеуМате>ип1:х-ос(ори5:8есгеГ-кеу.· 100! </Кеу№те>
</Кеу1п(о>
Случай К8А-8НА1.
В одном варианте осуществления, в этом случае, открытый ключ, используемый для проверки подписи, переносится в сертификате Х.509 ν3 и может сопровождаться другими сертификатами, которые могут быть необходимы для завершения пути от сертификата к корню СА.
Эти сертификаты переносятся, в кодировке Ьаке64, в элементах <Х509СегНПса1е>. Эти элементы <Х509Сегййса1е> внедрены в элемент <Х509Оа1а> дочерний по отношению к элементу <Кеу1п£о>, и появляется последовательно, начиная с сертификата ключа подписи. Сертификат корня обычно опускают.
Пример (для краткости, воспроизводятся не все значения иллюстративных сертификатов; опущенный материал указан многоточиями):
<Кеу1пГо>
<Х509Оа(а>
<!— сертификат открытого ключа подписи —>
<Х509Сегййса1е>М1]СЬ...</Х509Сегййса1е>
<!- промежуточный сертификат доверенного корня -> <Х509СеП1Йса1е>М11Со...</Х509СеП1йса1е>
</Х509Оа1а>
</Кеу1пГо>
В одном варианте осуществления, объекты «контроллер» должны иметь по меньшей мере одну подпись НМАС для каждого Со^^^Кеу, указанного в их списке управляемых целей. Ключ, используемый для каждой из этих подписей, представляет собой значение ключа контента, содержащегося в указанном объекте СогИегИКеу.
Контроллеры также могут иметь подпись К8А. В одном варианте осуществления, если такая подпись присутствует, эта подпись также появляется как <КеГегепсе> в каждой из подписей НМАС объекта. Для этого, в одном варианте осуществления, элемент <8|дпа1иге> для подписи К8А должен иметь атрибут '16', уникальный в охватывающем документе ΧΜΣ, который используется в качестве атрибута 'ЦК! в одном из элементов <КеГегепсе> каждой из подписей НМАС. В одном варианте осуществления, проверяющая сущность должна отвергать подписи К8А, не удостоверенные подписью НМАС.
Пример:
<8|£иа(иге 10-'5|£пай1ге.О хт1п5=Ьйр://т¥».иЗ .ог§/2000/09/хтИзц·#>
<8ц>пес11п(д>
<СапошсаНга1юпМе11ю(1 А1ЁОГ1Гкт=”Ь«р://тта'.и’3.оге/2001/10/хт1-ехс-с14п#”/> <8|®па(игеМе(Ьой А1§опЛт=11Пр:/Л1™га'.«'3.ог§/2000/09/хт1(1зц5#г5а-8ЬаГ'/> -КеГегепсе ЦЮ-'ипкхос1ори5пп1ег1ги5Усот:соп1го11ег:37А50262ЕЕ3389А14АВС0ВС7ВЕ5О43Е5>
<ТгапзГогтз>
<ТгапзГогт А1£оп(11т='Ъ(1р://т¥й.1п1ег1ги81.сот/Ос(ориз/хт1<1815#сЬ8-1_0/>
<Тгап5Гогт5>
<Р1®ез1Ме1Ьо<1 А1(рпШт=11Пр:/Луту.ч'3.ог&|2000/09/хт1<1з15#511а1 > <О1£е51Уа1ие>612ХР98г/гСч'Н6МаЕ|110ОЬО(}схи1с=<Л>ч’ез1Уа1ие> </Ке£егепсе>
</81£пе<ПпГо>
<8|8па«1ге\''а11|е>тюу'А’+'л’259|7ОС/Ъа4е\УУО1Кт1ЮидК11и8К977МООр™иО02Ес15А1СУ)Аси7{4г Р^цу1а«дас1Рг¥Р/р!РеЬЕ8СтагНи5ЕаК1/Ь¥Шкр^\¥х11/Е1Ер4гЗу1г9ки80Аи5а4ВОхОхОЕ7пиОчи 9УМрп)АгЕСрихс1Рег1М1¥уКдМ)рТк94=</5!8пагигеУа1ие>
<Кеу1иСо>
<Х5090а1а><Х509СеП1Яса(е>МПСй...<Х509Сегййса1ех/Х509Ца(а> <Кеу1пГо>
</8|§паП1ге'<8щпа1игехт1пз=11йр://т™.1у3.ог8/2000/09/хП11<|51б#>
- 95 012918 <5ί§ηεά1ηίΌ>
<Сапотиса112айопМ«Ь<х1 А1§огйЬт=Ькр :/Λν\νλν.νί3.οι·§!200 1 /10/хт1-ехс-с14п#/> <51§па1игеМеЙю<1 А1§огИ1ип=''йПр://\™ху.«3.огй/2000/09/хтМ51д#Ьтас-зЬаГ,/> <Ке£егепсе иК1=#8|ёпа1иге.0>
<Οι^ε5ΐΜοιϊιοά А1§оп1Ьт=Ь«р://т™.»3.ог8/200()/09/хт1<151£#зЬа1 /> <Οϊ§«5ίν81Μβ>ΑςΡνθηνΝ)/νο51ΙεΜγΚίη§6ΝΚ(Μ=</Οί§«5ΐν31υβ> </КеГегеп«> <Ке£егепсе ию=ит:х-осюри5лп<ег1п15(.сот:<х>п1го11ег: 1357>
<Тгап8Й>гт5>
<Тгап8Гогт А|£Оп(йт=кНР:/Лух™.1п»еПп!5ксот/0«ор118/хт1<1з1£#сЬ5-1_0'|/>
<'Тгап5Гогт5>
<Οί£ϊίΐΜβύιο<1 Α1£.οπϋιηι-Ίι«ρ://Ά4™,νΙ'3ΛΓ5/2000/09/χιη145Ϊ^$1ι<ιΓ'/> <О||е81Уа!ие>О1гХЕ952^гСиН6МаРт0ОЬО9схик=</О1£е51Уа1ие> </Ке(егепсе>
</Зщпес!1пСо> <81ёпа(игеУа1ие>ТсКВ522у+УрЗ(1оОк262ЬТ(У+п10=</3|§па1игеУа1ие> <Кеу1пй» <КеуКате>ип1:хч>Мори5ЛП1еПгия1.сот:5есгеУкеу:2001</КеуМате>
</Кеу1п!о> </51ипа1иге>
13. Протокол проверки близости.
В некоторых вариантах осуществления, может быть желательно ограничивать доступ к контенту, услугам и/или другим системным ресурсам на основании физической близости запрашивающей сущности (например, для применения правил, указывающих, что защищенный фрагмент контента нельзя копировать за пределы домашней сети пользователя, офисного комплекса, и/или т.п.). Ниже описаны варианты осуществления протокола проверки близости, которые обеспечивают безопасность без ненужного препятствования осуществлению самой проверки близости. Протокол проверки близости приспосабливается к приложению в разнообразных контекстах, один из которых, как указано выше, является контекстом объектов управления цифровыми правами; однако очевидно, что описанные ниже системы и способы проверки близости не ограничиваются применением к контексту управления цифровыми правами. Например, без ограничения, представленные здесь методы проверки близости также можно использовать в контексте системе согласования сетевых услуг, например описанной в заявке '551 и/или в любом другом подходящем контексте.
В одном варианте осуществления, проверка близости осуществляется путем измерения времени, которое требуется первому вычислительному узлу для приема ответа от второго вычислительного узла на запрос первого вычислительного узла.
Если промежуток времени меньше заранее заданного порога (что обычно указывает, что второй вычислительный узел находится в пределах определенного физического расстояния от первого вычислительного узла), то проверка близости считается успешной.
Очевидно, что вследствие большого разнообразия различных сетевых соединений, по которым могут передаваться запрос и/или ответ, данный промежуток времени может соответствовать диапазону различных расстояний. В некоторых вариантах осуществления, этот разброс просто игнорируется, и проверка близости считается успешной, если время цикла обмена сообщениями запрос/ответ меньше заранее заданного порога (например, 8 миллисекунд или любой другой подходящий промежуток времени), независимо от того, например, используется ли первое сетевое соединение, что может означать, что запрашивающий и отвечающий узлы действительно относительно отстоят друг от друга. В других вариантах осуществления, можно производить определение типа используемого сетевого соединения, и другие требования к циклу обмена сообщениями можно применять ко всем остальным сетевым соединениям.
В предпочтительном варианте осуществления, проверка близости позволяет анкеру (например, клиенту) проверять близость к цели (например, услуге). В одном варианте осуществления, протокол асимметричен, в том, что анкер генерирует секретное порождающее число, которое используется, и только он один использует защищенный таймер. Кроме того, цель не обязана доверять анкеру. Предпочтительные варианты осуществления проверки близости также криптографически эффективны: в одном варианте осуществления используются только две операции открытого ключа.
Генерация множества К из О пар на основе порождающего числа 8.
В одном варианте осуществления, множество К получается из порождающего числа 8 согласно следующей формуле: К1=Н2°-1(8). Здесь Н(М) это значение дайджеста хэш-функции Н над сообщением М, и Нп(М)=Н(Нп-1(М)) для п>=1 и Н0(М)=М. Очевидно, что это просто один иллюстративный метод генерации секрета совместного пользования, и что в других вариантах осуществления можно использовать другие методы, не отходя от его принципов.
В одном варианте осуществления алгоритм, используемый для хэш-функции Н, представляет собой 8НА1 (см., например, МР8 РИВ 180-1. 8есиге Накй 8кап6аг6. и.8. Оерайшеп! оГ Соттегсе/Ыа!юпа1 НлкП1п1е оГ 8!ап6аг6к апб Тесйпо1оду), хотя очевидно, что в других вариантах осуществления можно использовать другие хэш, дайджест сообщения или функции.
В одном варианте осуществления проверка близости осуществляется следующим образом, где А это анкер (например, клиент) и В это цель (например, услуга):
(а) А генерирует множество К из О пар случайных чисел {Ко, К!}, {К2, К3}... {К2р-2, К2р-1}, как пока
- 96 012918 зано выше.
(b) А передает В: Е(РиЬВ, {Р,8}), где Е(У, X) обозначает шифрование X ключом Υ, и РиЬВ обозначает открытый ключ для В в паре открытого/секретного ключей.
(c) В дешифрует Ю,8} и предварительно вычисляет К, как показано выше.
(ά) В передает А подтверждение приема, указывающее, что он готов продолжать.
(е) А задает счетчик циклов к равным нулю.
(Г) А измеряет Т0 = текущее время, (д) А передает В: {к, К2*к}.
(Ь) Если значение К2*к верно, В передает в ответ К2*к+!.
(ί) А измеряет Ό = новое текущее время - Т0.
(ί) Если В передало А верное значение для К2*к+1, и Ό меньше заранее заданного порога, то проверка близости считается успешной.
Если к+1<0, А может выполнить новое измерение, увеличив к и перейдя к этапу (Г). Если необходимо осуществить более О измерений, А может начать с этапа (а) с новым множеством К. Например, в некоторых вариантах осуществления проверку близости можно осуществлять повторно (или заранее заданное число раз) пока не будет получен верный ответ в пределах заранее заданного порога (или если верные ответы принимаются в пределах заранее заданного порога сверх заранее заданного процента последовательности вызовов/ответов), поскольку, даже если два вычислительных узла находятся в необходимой близости друг от друга, аномально медленное сетевое соединение, интенсивный трафик, шум и/или т. п. может привести к задержке ответа от В.
На фиг. 36 показан вариант осуществления вышеописанного протокола, в котором анкер (А) определяет, находится ли цель (В) в приемлемой близости от анкера (А). Например, согласно фиг. 36, А может содержать вычислительный узел 3602, который содержит защищенный контент (например, музыку, видео, текст, программное обеспечение и/или т.п.) и/или материал доступа к контенту (например, связь, ключ и/или т.п.), необходимый удаленному вычислительному узлу (В) 3606 для доступа к защищенному контенту, хранящемуся на вычислительном узле В 3606 или доступному ему. Объекты управления, связанные с контентом или материалом доступа к контенту, могут указывать, что его могут совместно использовать только устройства в определенной близости от узла А 3602 (например, для аппроксимации ограничения распространения контента на домашнюю сеть). Альтернативно или дополнительно, такую политику можно применять на системном уровне вычислительного узла А 3602 (который может, например, содержать менеджер доменов домашней сети или сети предприятия). Таким образом, проверка близости не обязана должна быть условием в программе управления, выполняемой виртуальной машиной; вместо этого она просто может быть чем-то, что вычислительный узел А 3602 требует в качестве предмета операционной политики прежде, чем отправить контент или материал доступа к контенту на вычислительный узел В 3606. Для применения таких объектов управления и/или политик, программное и/или аппаратное обеспечение, выполняющееся на вычислительном узле А 3602, может осуществлять вышеописанный протокол проверки близости каждый раз при подаче запроса на распространение защищенного контента или материала доступа к контенту на вычислительный узел В 3606. Альтернативно или дополнительно, проверка близости можно осуществлять с заранее заданными интервалами (например, раз в день) для определения, находится ли узел В 3606 в необходимой близости, и, в случае успешной проверки близости, можно считать, что узел В 3606 находится в необходимой близости в течение заранее заданного периода (например, до осуществления следующей проверки, до истечения заранее заданного времени, и/или т.п.).
Согласно фиг. 36, когда А и В завершают все начальные этапы установки (например, вышеописанные этапы (а)-(е)) 3604, 3608, А и В начинают защищенный, хронируемый обмен вызовами-ответами (например, на вышеописанных этапах (Г)-(1)) 3610, который позволяет А определить, находится ли В в приемлемой близости.
Согласно фиг. 36, в одном варианте осуществления А 3602 передает В 3606 запрос установки 3604, содержащий Е (РиЬВ, Ю, 8}), т.е. число пар О, а также секретное порождающее число 8 для пар, зашифрованное открытым ключом шифрования для В (например, ключом, который В используется в контексте согласования услуг). В одном варианте осуществления, [р, 8} представляет собой поток байтов, сцепляющий Р (1 байт) и 8 (16 байтов) в сетевом порядке следования байтов. В одном варианте осуществления, шифрование осуществляется с использованием шифрования открытым ключом К8А (например, как описано в В. Ка11кк1, к 8ΐаάάои, РКС8 #1; К8А Сгур1одгарйу кресШсайоик Уегкюи 2.0. 1ЕТР КЕС2437. ОсЮЬег 1998). В предпочтительном варианте осуществления, А предварительно осуществляет доступ к РиЬВ в порядке инспекции, и его сертификат проверяется. Хотя на фиг. 36 показан ответ установки 3608 от В 3606 к А 3602, в других вариантах осуществления, ответ установки 3608 не используется. Как указано выше, получив запрос установки 3604, В 3606, предпочтительно, предварительно вычисляет множество К, что способствует быстрому ответу на последующие вызовы от А 3602.
Согласно фиг. 36, А 3602 передает В запрос вызова 3612, состоящий из [к, К2*к], т.е. индекса к и соответствующего секрета, вычисленного из порождающего числа. В одном варианте осуществления, [к, К2*к] представляет собой поток байтов, сцепляющий к (1 байт) и К2*к (20 байтов) в сетевом порядке следования байтов, в кодировке Ьаке64 для переноса. Согласно фиг. 36, в одном варианте осуществления, В
- 97 012918
3606 способен передавать ответ вызова 3614 на А 3602, причем ответ вызова 3614 состоит из К.2*к+1, т.е. соответствующего секрета из запроса вызова 3612. В одном варианте осуществления, Н2*к+1 представляет собой поток байтов Н2*к+1 (20 байтов) в сетевом порядке следования байтов, в кодировке Ьа§е64 для переноса.
На фиг. 37 показан пример того, как можно использовать вариант осуществления вышеописанного протокола проверки близости для управления доступом к защищенному контенту. Согласно фиг. 37, предположим, что кабельный или спутниковый поставщик контента имеет политику, позволяющую всем устройствам в заранее заданной близости 3708 от персонального видеомагнитофона (ΡνΚ) 3702 пользователя осуществлять доступ к контенту через ΡνΚ. Таким образом, например, программное обеспечение менеджера доменов, выполняющееся на ΡνΚ 3702, может осуществлять проверку близости на устройстве 3704 и 3706, запрашивая доступ к контенту через ΡνΚ 3702. В примере, показанном на фиг. 37, устройство 3706 не находится в пределах близости 3708, заданных политикой поставщика услуг, и получает от ΡνΚ 3702 отказ в доступе. Напротив, устройство 3704 находится в пределах близости, и получает доступ, например, принимая контент совместно со связью ограниченного периода действия от устройства 3704 на ΡνΚ 3702. Альтернативно или дополнительно, связь может содержать программу управления, которая способна самостоятельно инициировать проверку близости к ΡνΚ 3702 и отказывать устройству 3704 в дальнейшем доступе к контенту, если бе\зсе 3704 перемещается за пределы заранее заданной близости 3708 к ΡνΚ 3702.
Соображения безопасности
В предпочтительных вариантах осуществления, следует обратить внимание выполнению некоторых или всех из следующих условий:
цикл, содержащий этапы (Г)-(1) не повторяется с одним и тем же значением к для любого множества Κ;
протокол прерывается, если какая-либо сторона принимает неожиданное сообщение, в том числе: если В принимает неверное значение для на этапе (д);
если О не находится в указанном диапазоне на этапе (а);
если к повторяется в цикле;
если к превышает О.
Протокол может альтернативно или дополнительно прерываться, если А принимает неверное значение Κ^+ι на этапе (к). В других вариантах осуществления допустимо определенное количество неверных ответов от В.
Очевидно, что оптимальные значения для О и заранее заданный временной порог обычно зависят от уникальных условий конкретного применения (например, скорости сети, важности обеспечения относительно тесной близости и т.д.). Поэтому предпочтительно обеспечивать гибкость реализаций в установлении этих значений. В одном варианте осуществления предполагается, что реализации поддерживают минимальное значение О, равное 64, и значение порога, равное 8 мс (причем, для некоторых современных скоростей сети, 8 мс может соответствовать расстоянию в несколько миль).
Политики безопасности протокола.
В предпочтительном варианте осуществления, для обмена запросами и ответами не требуется никакой дополнительной защиты. Ввиду размера передаваемых сообщений (например, 20 байтов), и их эффективной случайности (при использовании алгоритма хэширования 8ΗΑ1 или другого метода), для нарушителя криптографически невыполнимо определение верного ответа, даже если нарушитель способен перехватывать запрос.
Очевидно, что вышеописанные варианты осуществления являются иллюстративными, и что можно предложить многочисленные модификации, не отклоняясь от представленных здесь принципов изобретения. Например, хотя выше описано рекурсивно хэшированное секретное порождающее число, для вызова/ответа можно использовать любой подходящий секрет совместного пользования. В одном варианте осуществления, секрет совместного пользования может просто содержать зашифрованное число/сообщение, передаваемое от А к В, и вызов/ответ может просто содержать обмен между А и В фрагментами числа/сообщения (например, А передает В первый символ сообщения, и В передает А второй символ сообщения, и т.д.). Хотя такому методу может недоставать защищенности, характерной для варианта осуществления, описанного в связи с фиг. 36 (поскольку символ в сообщении гораздо легче разгадать, чем 20-байтовый хэш), в некоторых вариантах осуществления такой уровень безопасности может быть достаточным (в особенности, когда, например, изменчивость сетевых задержек, так или иначе, делает механизм проверки близости весьма грубым средством контроля фактической близости), тогда как в других вариантах осуществления безопасность нужно повысить, осуществляя проверку близости несколько раз, где, хотя любую конкретную цифру или бит сравнительно легко угадать, вероятность того, что нарушитель сможет правильно разгадать данную последовательность цифр или битов, быстро уменьшается с увеличением длины последовательности. В этом варианте осуществления проверку близости можно считать успешной, только если В способен обеспечить свыше заранее заданного количества верных ответов подряд (или свыше заранее заданного процента верных ответов).
В целях иллюстрации и объяснения, ниже представлен дополнительный иллюстративный пример
- 98 012918 протокола проверки близости. В этом примере, первое устройство, 8КС, осуществляет связь со вторым устройством, 8ΝΚ, по каналу связи (например, компьютерной сети). Мы хотим иметь возможность безопасно определять, близки ли 8КС и 8ΝΚ друг к другу, что измеряется временем, необходимым 8ΝΚ для ответа на запрос установления связи от 8КС. Вызов или пробное сообщение передается от 8КС на 8ΝΚ, и 8ΝΚ отвечает ответным сообщением. Период времени между отправкой вызова и приемом ответа называется временем цикла обмена или КТТ. Во избежание внесения дополнительной задержки в период времени, которое требуется 8ΝΚ для вычисления и отправки назад ответа на вызов, обычно желательно, чтобы передача вызовов/ответов была как можно более «легкой». В частности, обычно желательно избегать условий, когда 8КС или 8ΝΚ требует осуществления криптографических операций между отправкой вызова и приемом ответа.
Кроме того, чтобы гарантировать, что только 8ΝΚ способен создавать правильный ответ на вызов от 8КС (например, во избежание атаки перехватчика, когда третья сторона перехватывает вызов от 8КС и посылает назад ответ под видом 8ΝΚ), протокол должен выполняться следующим образом:
(1) 8КС создает секрет. Этот секрет состоит из одной или нескольких пар случайных или псевдослучайных чисел.
(2) 8КС передает секрет на 8ΝΚ. Эта часть протокола не зависит от времени. 8КС и 8ΝΚ хранят секрет в тайне. Секрет также передается таким образом, чтобы гарантировать, что его знает только 8ΝΚ. Для этого обычно предусмотрена передача секрета по защищенному аутентифицированному каналу между 8КС и 8ΝΚ (например, 8КС может шифровать секретные данные открытым ключом, про который он знает, что только 8ΝΚ имеет соответствующий секретный ключ). Секретные данные не обязаны быть вышеописанной(ыми) парой(ами) случайных или псевдослучайных чисел. Даже согласно вариантам осуществления, где используются такие пары, секретные данные, передаваемые на этом этапе, должны лишь содержать достаточно информации, чтобы 8ΝΚ мог вычислить или вывести значения пар чисел. Например, секретные данные могут быть случайным порождающим числом, из которого можно сгенерировать одну или несколько пар псевдослучайных чисел с использованием генератора псевдослучайных чисел на основе порождающего числа.
(3) Когда 8КС знает, что 8ΝΚ готов принять вызов (например, 8ΝΚ может отправить сообщение ПЕАРУ после приема и обработки секретных данных), 8КС создает сообщение вызова. Для создания сообщения вызова. Например, в предпочтительном варианте осуществления, 8КС выбирает одну из пар случайных чисел. Если используется более одной пары, данные сообщения вызова содержат информацию, указывающую, какая пара выбрана, а также одно из двух чисел этой пары.
(4) 8КС измеряет значение текущего времени Т0. Сразу после этого 8КС передает сообщение вызова (шифрование или цифровая подпись не требуется) на 8ΝΚ и ожидает ответа. Альтернативно, 8КС может измерить текущее время Т0 сразу после отправки сообщения вызова, хотя, предпочтительно, после осуществления каких-либо соответствующих криптографических операций (например, шифрования, подписывания и/или т.п.).
(5) 8ΝΚ принимает вызов, на основании которого он может идентифицировать одну из пар, принятых им ранее. 8ΝΚ удостоверяется, что случайное число в вызове является частью пары, и строит ответное сообщение, которое содержит значение другого случайного числа этой пары.
(6) 8ΝΚ передает ответное сообщение на 8КС (шифрование или цифровая подпись не требуется).
(7) 8КС принимает ответное сообщение и измеряет значение текущего времени Т1. Время цикла обмена КТТ равно Т1-Т0.
(8) 8КС удостоверяется, что число, полученное в ответе, равно другому значению в паре, которая была выбрана для вызова. Если числа совпадают, ответ вызова является успешным, и 8КС может быть уверен, что 8ΝΚ отвечает той степени близости, которая определяется временем цикла обмена. Если числа не совпадают, 8КС может прервать протокол или, если совместно используется более одной пары, и существует по меньшей мере одна пара, которая не была использована, возвратиться к этапу (3) и использовать другую пару.
Очевидно, что вышеописанные иллюстративные протоколы проверки близости допускают ряд изменений, не отклоняющихся от его принципов. Например, без ограничения, можно использовать другие криптографические алгоритмы, можно использовать другие секреты совместного пользования и/или т. п.
14. Безопасность.
В практических применениях описанных здесь систем и способов, безопасность можно обеспечивать на различных уровнях и с использованием различных методов. Нижеследующее рассмотрение относится, в основном, к конструкции и принципу работы механизма ΌΠΜ и соответствующего приложения хоста для использования с целью эффективной регуляции потенциально сложных деловых отношений. Когда механизм ΌΠΜ и приложение хоста действуют надлежащим образом, осуществляется защита контента от неавторизованного доступа или иного использования за счет применения условий связанной с ним лицензии.
Защиту механизма ΌΠΜ и/или среды, в которой выполняется механизм ΌΠΜ (например, приложения и оборудование, с которым он взаимодействует) от злонамеренной подделки или модификации можно осуществлять с использованием любой подходящей комбинации методов безопасности. Например,
- 99 012918 можно применять такие криптографические механизмы, как шифрование, цифровые подписи, цифровые сертификаты, коды аутентификации сообщения, и т.п., например, описанные здесь в другом месте, для защиты механизма ΌΚΜ, приложения хоста и/или другого системного программного обеспечения или оборудования от подделки и/или иных атак, которые могут представлять собой структурные и/или тактические меры безопасности, например, умышленное придание непонятности программному обеспечению, самопроверка, разработка заказных модулей, создание «водяных знаков», противодействие средствам отладки и/или иные механизмы. Иллюстративные примеры таких методов можно найти, например, в патенте США № 6,668,325 В1, ОЬГизсабоп МеИобз Гог ЕпБапсшд 8оП\уаге 8есигбу, и в совместно присвоенной патентной заявке США № 11/102,306, опубликованной под номером υδ-2005-0183072-Α1; патентной заявке США № 09/629,807; патентной заявке США № 10/172,682, опубликованной под номером υδ-2003-0023856-Α1; патентной заявке США № 11/338,187, опубликованной под номером υδ-20060123249-А1; и в патенте США № 7,124,170 В1, 8есигеб Ргосеззтд υπίΐ 8у51етз апб МеШобз, которые все, таким образом, включены сюда посредством ссылки в полном объеме. Альтернативно или дополнительно, можно использовать физические методы безопасности (например, использование относительно недоступной памяти, защищенных процессоров, защищенных блоков управления памятью, режимов работы операционной системы с аппаратной защитой и/или т.п.) для дополнительного повышения безопасности. Такие методы безопасности общеизвестны специалистам в данной области техники, и, очевидно, что можно использовать любую подходящую комбинацию из некоторых, ни одного или всех этих методов в зависимости от нужного уровня защиты и/или особенностей конкретного применения. Таким образом, очевидно, что, хотя здесь описаны определенные механизмы безопасности (например, методы вывода ключа, методы цифровой подписи, методы шифрования, и т.п.) в связи с определенными вариантами осуществления, не все варианты осуществления предусматривают использование этих методов.
Еще одна форма безопасности может обеспечиваться институциональной конструкцией и работой системы, а также юридической и социальной регуляцией ее участников. Например, для получения узла индивидуальности, материала, зашифрованного ключом, защищенного контента, и/или т.п., от устройства или сущности может понадобиться подтвердить свое согласие следовать спецификациям и требованиям системы, может понадобиться пройти процесс сертификации, в ходе которого проверяется согласованность сущности с системными требованиями, и/или т. п. Например, устройству или приложению может понадобиться реализовать механизм ΌΚΜ таким образом, чтобы он был совместимым с другими реализациями в среде, и/или может понадобиться обеспечить определенный тип или уровень защиты от подделки или иных защитных средств. Можно выдавать цифровые сертификаты, свидетельствующие о согласовании устройства или иной сущности с такими требованиями, и эти сертификаты можно проверять до дачи разрешения устройству или сущности участвовать в системе, или как условие предоставления постоянного доступа.
Ниже представлена дополнительная, неограничительная информация по методам безопасности, которые можно использовать согласно изобретению.
Защита системы
В некоторых вариантах осуществления, разработчик системы может, по своему выбору, использовать сочетание методов обновляемости, отказа и/или исправления для управления рисками и ослабления угроз, которые могут возникать вследствие атак на устройства, приложения и службы или их компрометации. Ниже представлены примеры различных технических механизмов, которые можно использовать для ослабления угроз.
Механизмы обновления можно использовать по меньшей мере в двух различных целях. Во-первых, их можно использовать для передачи обновленной информации доверенным системным сущностям, которая позволяет им отказывать в доступе или обслуживании недоверенным системным сущностям. Вовторых, механизмы обновления позволяют недоверенной сущности восстановить доверенное состояние путем обновления любого скомпрометированного компонента. Отказные контрмеры можно дополнительно охарактеризовать как демонстрирующие один или несколько из следующих режимов поведения:
Отмена или аннулирование мандата (обычно, путем занесения какой-либо сущности в черный список);
Исключение или блокировка доступа путем применения криптографических механизмов или механизмов применения политики;
Бойкот или блокировка доступа или обслуживания на основании идентичности или какого-либо другого атрибута, привязанного к мандату;
Прекращение действия или аннулирование мандата или привилегии на основании временного события.
Например, механизмы отказа можно использовать для противодействия таким угрозам, как клонирование устройства, маскировка под законного пользователя, сбои протокола, сбои в применении политики, сбои в защите приложений и устаревшая или подозрительная информация.
В нижеследующей таблице приведены примеры потенциальных угроз, некоторых рисков, которые они представляют, и механизмов противодействия угрозам и обновления защиты системы.
- 100 012918
| Угроза | Риски | Механизм исправления | Механизм обновлении |
| Клонирование устройства | Свободный доступ к устройствам. | Шифрование вещания | Обновление ВКВ. |
| Скомпрометированный сертифицированный ключ | Неавтор изованные лицензии, связи, состояние устройства, идентичности, доступ к службе. | Отмена сертификата | Распространение СКЬ. Обновление ключа. |
| Сбой реализации | Средство взлома устройства. | Указание версии спецификации | Обновление программного обеспечения |
| Сбой протокола | Скомпрометированные ключи. Нерегулируемый доступ к ли авизированному контенту. | Задание метаданных безопасности | Обновление программного обеспечения |
| Устаревшие метаданные безопасности | Фальшивое взаимодействие служб. Обратный ход часов, опора на скомпрометированную информацию. | Задание метаданных безопасности | Служба обновления метаданных безопасности. Обновление программного обеспечения. |
Отмена
Отмену можно рассматривать как механизм исправления, опирающийся на занесение сущности в черный список. Обычно отменяется мандат, например, сертификат открытого ключа. После отмены мандата, черный список нужно обновить и использовать механизм обновления для переноса обновления, чтобы заинтересованная сторона могла извлечь из него пользу.
Таким образом, например, можно потребовать, чтобы устройства, пользователи и/или другие сущности представили сертификаты идентичности, другой мандат и различные данные безопасности, прежде чем предать им информацию, необходимую для потребления контента или услуги. Аналогично, чтобы клиент доверял службе, можно потребовать, чтобы служба представила свой мандат клиенту.
Примеры того, как сущность может эффективно сделать недействительной информацию, необходимую для доступа к службе, включают в себя:
списки отмены сертификата (СКЕ);
службы действительности мандата и данных, например, ответчик протокола Оп1ше СегйПса1е 8ΐ;·ιΙιΐ5 РгоЮсо1 (ОС8Р);
команды самоуничтожения мандата и данных.
Списки отмены сертификата (СКЬ)
Различные сущности могут использовать списки отмены для отмены сертификатов идентичности, лицензий, связей и других утверждений безопасности. Этот механизм наиболее эффективен для исправления ситуации, которая возникает вследствие компрометации службы. Можно использовать ряд методов для распространения СКЬ. Например, некоторые системы могут применять косвенный СКЬ, т.е. существует единственный СКЬ, управляющей всей экосистемой. Кроме того, сущности могут объявлять (или публиковать) имеющиеся у них СКЬ и/или подписаться на услугу обновления. СКЬ можно виртуально распространять между равноправными устройствами, и/или портативные устройства могут получать опубликованные СКЬ, будучи привязанными. С этой целью также можно использовать методы согласования услуг, описанные в заявке '551.
Службы действительности
Службы действительности можно использовать для обеспечения обновленной информации о состоянии мандата и других данных, связанных с безопасностью. Службы действительности могут осуществлять либо операции активного удостоверения от имени заинтересованной стороны, либо могут использоваться для управления информацией безопасности от имени заинтересованной стороны. Примером активной службы действительности является служба, которая может проверять действительность мандата или атрибута. Примерами служб действительности, которые управляют информацией безопасности, являются службы, которые распространяют СКЬ или обновления политики безопасности, или обеспечивают защищенную службу времени. Использование служб действительности позволяет гаран
- 101 012918 тировать, что заинтересованные стороны имеют обновленные данные для принятия решений по управлению.
Обычно не всем системным сущностям требуется ежеминутно обновляемая информация о действительности мандата и данных безопасности. Например, не все потребительские устройства используют службу ОпКпе СегиПсаЮ 8(а(ик Рго!осо1 (ОСЗР) для удостоверения цепи сертификатов сервера лицензий каждый раз при использовании лицензии или получении новой лицензии. Однако сервер лицензий может достаточно часто использовать службу ОСЗР для проверки действительности мандата подписчика. Политика (которую легко обновлять) может определять, когда и какие службы нужно использовать. Благодаря возможности динамически обновлять политику, серверы лицензий могут адаптироваться к изменениям условий работы. Таким образом, политика безопасности может развиваться на основании опыта, технологического прогресса и рыночных факторов.
Принудительное самоуничтожение объектов безопасности
Самоуничтожение мандата и данных сущностью имеет смысл, когда целостность защитных процессов сущности не вызывает сомнений. При наличии такой возможности, это, зачастую, является наиболее прямым, быстрым и эффективным методом отмены. Это может быть особенно полезно, при наличии малого или, вовсе, отсутствия подозрений в нарушении целостности, и когда двусторонняя связь поддерживает протокол, допускающий конкретные команды уничтожения совместно с проверкой, что это уничтожение было произведено.
Существует ряд объектов безопасности, которые часто бывает полезно уничтожать или отключать. Например, когда устройство покидает домен, или заканчивается срок действия лицензии контента, бывает полезно уничтожить соответствующие объекты, которые содержат ключи и которые можно использовать для доступа к контенту. Агентские программы управления, более подробно описанные в другом месте, весьма пригодны для реализации механизмов самоуничтожения. Агенты можно приспособить для уничтожения состояния в защищенном хранилище (например, базе данных состояний) для актуализации изменений в доменной принадлежности или для удаления ключей, которые уже невозможно использовать (например, вследствие изменений в принадлежности или политике).
Исключение
Исключение это механизм исправления, который препятствует злонамеренному пользователю (или группе злонамеренных пользователей) участвовать в дальнейшем потреблении товаров и услуг. В силу суровых последствий исключения, оно обычно используется как последнее средство, когда этого требуют обстоятельства. Исключение базируется на механизме, который эффективно заносит в черный список злонамеренных пользователей, тем самым запрещая им потреблять медиа-ресурсы и связанные с ними услуги. Распространение черного списка опирается на механизм обновления для обеспечения этого исправления. Однако исключение не обязательно обеспечивает механизм обновления для восстановления злонамеренного пользователя в доверенное состояние.
Исключение ключа
Исключение ключа это механизм управление ключами, который используется для рассылки информации ключа множеству приемников таким образом, чтобы в любое данное время можно было принять решение на логическое лишение некоторого подмножества приемников возможности дешифровать контент в будущем. Этот механизм активируется с использованием эффективных методов построения Блока рассылки ключей (ВКВ), который включает в себя информацию, необходимую каждому члену большой группы приемников для дешифрования контента. ВКВ имеет структуру, позволяющую легко обновлять его, чтобы лишить одного или нескольких членов группы возможности дешифровать контент. Иными словами, конструкция ВКВ позволяет управляющей сущности обновлять систему новым ВКВ, что позволяет поставщику контента избирательно исключать нужное множество устройств из пользования ВКВ, даже если оно может обращаться к нему.
Этот механизм особенно эффективен против атаки клонирования, когда пират обращает инженеров к законному устройству, извлекает его ключи и затем использует копии этих ключей для клонирования устройств. Клоны внешне действуют как оригинал, за исключением того, что эти клоны не всегда следуют модели администрирования. Когда компрометация выявлена, можно распространить обновленный ВКВ, который исключает скомпрометированное устройство и все его клоны. Однако исключение ключа влечет за собой некоторую избыточную нагрузку, связанную с хранением, переносом и вычислением, что, в ряде случаев, делает его менее эффективным по сравнению с другими методами. Это особенно верно, когда контент не подлежит вещанию, или когда существует обратный канал.
Бойкот
Бойкот это механизм исправления, действующий аналогично исключению, но с менее суровыми последствиями. По существу, это средство отказа в обслуживании по решению политики среды выполнения. Вместо более тяжеловесных подходов к лишению устройства дееспособности путем принудительного самоуничтожения или блокировки доступа посредством исключения ключа, бойкот предусматривает простой подход к отключению устройства за счет того, что поставщики услуг отказываются предоставлять ему услуги. При современной тенденции к повышению значимости устройств за счет использования услуг, предоставляемых извне, бойкот становится более эффективным механизмом безопасно
- 102 012918 сти.
Бойкот устройства инициируется политикой, и его можно использовать для обеспечения дискриминационных мер против сущностей (например, клиентов, серверов и конкретных ролевых игроков) которые не предъявляют все необходимые мандаты, которые требует политика. Политика, например, может требовать, чтобы сущность продемонстрировала, что она получила последнее обновление безопасности. Поэтому бойкот может быть следствие либо отмены, либо неудачной попытки совершить какое-либо конкретное действие. Бойкот в среде взаимодействия равноправных устройств с использованием можно обеспечить с помощью инспекционных служб и таких служб, которые, например, описаны в заявке '551. Кроме того, служба сертификации данных (например, экземпляр службы действительности) может осуществлять бойкот в момент применения политики. Когда системная сущность бойкотирована, ей можно сообщить, какой конкретный мандат или объект не отвечает требованиям политики службы. Это может побудить бойкотируемую сущность к обновлению объекта через соответствующий интерфейс службы.
Прекращение действия
Прекращение действия это механизм исправления, который опирается на некоторое временное событие для объявления мандата или объекта недействительным. Прекращение действия эффективно при предоставлении временного доступа к медиа-ресурсам или медиа-услугам; по истечении его срока действия, модель администрирования гарантирует, что доступ более не разрешен. Для эффективного использования прекращения действия могут потребоваться механизмы обновления, позволяющие обновить мандат или объект для обеспечения продолжения доступа к медиа-ресурсам или медиа-услугам.
Прекращение действия мандатов
Сертифицированные ключи имеют различные атрибуты прекращения действия, присвоенные для защиты заинтересованных сторон. Прекращение действия мандат можно использовать для гарантии того, что сущностям, срок действия сертификатов которых истек, будет отказано в обслуживании, и использовать совместно с процедурами пролонгации ключа и обновления ключа. Когда предполагается, что сущности часто подключаются к глобальной сети, с практической точки зрения целесообразно регулярно обновлять мандат и другие данные безопасности. Другая практическая мера состоит в том, чтобы сделать период действия этих объектов как можно короче. В политиках проверки действительности можно использовать различные методы, например, перекрывающиеся периоды действия и льготные периоды, чтобы обеспечить непрерывность работы во время транзакций. Короткие периоды действия также помогают уменьшить размер СНЬ.
Прекращение действия связей
Как описано выше, объектам «связь» можно присваивать периоды действия. По истечении срока действия, связь считается недействительной, и механизм ΌΚΜ не учитывает ее при построении своего графа. Этот механизм можно использовать для обеспечения временного доступа к товарам и услугам. Связи можно обновлять, чтобы непрерывный доступ к медиа-ресурсам можно было предоставлять, пока это разрешает политика. Поскольку, в одном варианте осуществления, связи являются сравнительно легкими, самозащищенными объектами, их легко распространять по протоколам взаимодействия равноправных устройств.
Механизмы обновляемости: обновляемость приложений и политик
Эффективная обновляемость обычно обеспечивает быстрое применение исправлений к сбоям протокола, которые часто являются основными проблемами безопасности, возникающими в сфере обеспечения безопасности (в том числе, в системах ΌΚΜ). Обновления программного обеспечения можно использовать для обновления бизнес-логики и протоколов безопасности. Когда приложения приспособлены к политике безопасности и политике доверия, отдельно от логики приложения, можно использовать отдельный механизм для обновления политики; это менее рискованный подход. Фактически, можно использовать механизмы публикации между равноправными устройствами для быстрого обновления политики. В противном случае, можно использовать методы обновления программного обеспечения разработчика приложения для обновления политик безопасности и доверия.
Использование инструмента прав для правовой работы
Обычно желательно использовать относительно легкие инструменты, когда возможно. Использование мандатов с ограниченными периодами действия и политик, которые проверяют даты окончания срока действия, способствует поддержанию общей совокупности сущностей в управляемых пределах и избавляет от необходимости в слишком быстром увеличении размеров СНЬ. Бойкот сущности вместо лишения ее доступа к ключам может увеличивать срок действия ВКВ; кроме того, его преимущество состоит в обеспечении дифференцируемых политик, которые могут иметь временный характер и изменяться в зависимости от обстоятельств. Разные СИЕ, которые отслеживают конкретные типы мандата, представляющие интерес для различных ролевых игроков, можно использовать вместо ВКВ, которые можно распространять там, где они наиболее эффективны (например, имея дело с клонированными приемниками). Политики могут предписывать использование онлайновых служб действительности, когда предполагается, что эти службы обеспечивают разумную компенсацию затрат времени и усилий, когда свежие мандаты очень важны, и когда более медленные механизмы отмены непригодны. Когда узел, предположительно, обладает целостностью и совершает правильные действия, и когда объект лицензии или безо
- 103 012918 пасности (например, связь для подписки или связь домена) подлежит отмене, то разумный подход обычно состоит в предписании узлу уничтожить объект. В такой ситуации, нет необходимости объявлять лицензию недействительной и нет необходимости распространять ВКВ или повторно снабжать домен ключом. Самоуничтожение, инициируемое локальной политикой или самостоятельной командой, является одним из более эффективных методов отмены.
Очевидно, что хотя были описаны разнообразные технологии отмены, обновления, исправления и другие технологии и практики, очевидно, что для разных ситуаций используются разные инструменты, и что предпочтительные варианты осуществления описанных здесь систем и способов можно практически применять с использованием любой подходящей комбинации из некоторых или ни одного из этих методов.
Защита сетевых служб
В нижеследующем рассмотрении представлены некоторые соображения и методы безопасности, которые могут относиться к вариантам осуществления, в которых вышеописанные механизм ΌΚΜ и приложения используются в связи с системами и способами согласования сетевых служб, например, описанными в заявке '551.
Практические реализации систем ΌΚΜ, используемые механизмом и архитектурой ΌΚΜ, например, раскрытыми здесь, часто осуществляют сетевые транзакции для доступа к контенту и объектам ΌΚΜ. В таком контексте, системы и способы, описанные в заявке '551, можно использовать, в том числе, для стандартизации защиты на уровне сообщений, включающей в себя аутентификацию сущностей и форматы атрибутов авторизации (ролей).
В целях рассмотрения, транзакции, которые происходят в системе ΌΚΜ, можно разделить на по меньшей мере две общие категории на основании типа информации, к которой осуществляется доступ, которую получают, или над которой производятся манипуляции.
Транзакции доступа к контенту предусматривают прямой доступ или манипулирование мультимедийным или развлекательным контентом или другой важной информацией, защищаемой системой ΌΚΜ. Примеры транзакций доступа к контенту включают в себя представление защищенного видеоклипа, создание копии защищенного аудиотрека на компакт-диске, перемещение защищенного файла на портативное устройство, передачу конфиденциального документа по электронной почте и т.п. Транзакции доступа к контенту обычно предусматривают прямой доступ к ключу защиты контента и осуществляются на месте потребления по требованию пользователя.
Объектные транзакции это транзакции, в которых пользователь или система получает или взаимодействует с объектами, заданными системой ΌΚΜ, которая тем или иным образом регламентирует доступ к защищенному контенту. Такие объекты включают в себя лицензии ΌΚΜ, жетоны принадлежности, списки отмены и т.д. Одна или несколько объектных транзакций обычно необходимы прежде, чем будет доступно все обеспечение, необходимое для осуществления транзакции доступа к контенту. Объектные транзакции обычно характеризуются использованием того или иного типа сети связи для сборки объектов ΌΚΜ на месте потребления.
Эти два типа транзакций задают два пункта управления, которые, в общем случае, относятся к большинстве систем ΌΚΜ. На фиг. 38 показана типичная пара взаимодействий, в которых клиент 3800 с наличием ΌΚΜ запрашивает лицензию ΌΚΜ 3802 у соответствующей службы 3804 лицензий ΌΚΜ. В примере, показанном на фиг. 38, лицензия ΌΚΜ 3802 передается от службы 3804 лицензий ΌΚΜ на клиент 3800, где она оценивается для обеспечения доступа к контенту 3806.
Системы ΌΚΜ обычно требуют, чтобы транзакции доступа к контенту и объектные транзакции осуществлялись таким образом, что препятствовать неавторизованному доступу к контенту и создавать объекты, защищающие контент. Однако вопросы безопасности для двух типов транзакций принципиально различны. Например: транзакции доступа к контенту могут требовать аутентификации принципалачеловека, проверки защищенного счетчика представления, оценивания лицензии ΌΚΜ для вывода ключа защиты контента, и т. д. Основной угрозой законному выполнению транзакции доступа к контенту является нарушение границы, устойчивой к подделке, которая защищает объекты и данные внутри.
Объектные транзакции обычно предусматривают канал связи между сущностью, которая требует объект ΌΚΜ, и сущностью, которая его обеспечивает. По этой причине объектные транзакции сталкиваются с угрозами на основе связи, например атаками перехватчика, атаками ретрансляции, атаками отмены услуг и атаками, в которых неавторизованные сущности получают объекты ΌΚΜ, которые они не могут законно обрабатывать.
В общем случае, объектные транзакции предусматривают аутентификацию двух взаимодействующих сущностей, защиту сообщений, передаваемых между ними, и авторизацию транзакции. Основной целью таких транзакций является сбор объектов ΌΚΜ с защищенной целостностью из законных источников, что позволяет осуществлять транзакции доступа к контенту. С точки зрения транзакции доступа к контенту, механизмы, посредством которых получаются законные объекты ΌΚΜ и дополнительная информация, используемая при их получении, по существу, не имеют значения; эти механизмы могут (и, предпочтительно, должны) быть невидимыми для самого доступа к контенту. Это принципиальное разделение вопросов приводит, в предпочтительном варианте осуществления, к многоуровневой модели
- 104 012918 связи, которая отличает доверенную инфраструктуру связи от приложений, надстроенных на ней.
Упрощенный пример получения лицензии и потребления, показанный на фиг. 38, затемняет некоторые детали, которые обычно играют важную роль в практическом применении. Например, в этом примере не показано, как служба лицензий ΌΡΜ удостоверяется, что сущность, запрашивающая лицензию ΌΡΜ, действительно является законным клиентом ΌΡΜ, а не злонамеренной сущностью, пытающейся получить неавторизованную лицензию или заблокировать обслуживание законных клиентов путем потребления полосы сети и мощности обработки. Также не показано, как осуществляется защита важной информации в отношении конфиденциальности и целостности при ее переносе по каналам связи, соединяющим клиент и службу.
Эта иллюстративная транзакция более подробно показана на фиг. 39. На фиг. 39 пунктирная линия представляет логическую транзакцию с точки зрения клиента 3800 представления контента и сервера 3804 лицензий ^ΡΜ на уровне приложений. Стек 3900, изображенный под ними, представляет уровни обработки, используемые для обеспечения доверенной и защищенной доставки между двумя конечными точками.
Согласно фиг. 39, клиент представления 3800 запрашивает лицензию 3802 у сервера 3804 лицензий ^ΡΜ. Пунктирная линия на этой схеме указывает, что оригинальный источник и конечный потребитель информации представляют собой клиент 3800 представления контента и сервер 3804 лицензий ^ΡΜ. Однако, на практике, полезная нагрузка сообщения фактически может обрабатываться на нескольких уровнях обработки, находящихся между логикой уровня приложений и незащищенным каналом связи 3902, соединяющим две конечные точки.
Уровни обработки, которые отделяют компоненты уровня приложений от незащищенного канала связи, совместно называются стеком безопасности. Стек безопасности можно рассматривать как защищенную инфраструктуру обмена сообщениями, которая гарантирует, конфиденциальную передачу, с защитой целостности, сообщений между доверенными конечными точками. Многоуровневая модель стека обеспечивает следующие преимущества:
(1) Конструкторам логики уровня приложений не нужно тратить усилий на разработку нижележащих механизмов защищенной связи, которые соединяют конечные точки. Доверенный инфраструктуры обмена сообщениями является общим шаблоном конструкции, который, будучи однажды построен, может быть распространен на многие разные ситуации независимо от логики уровня приложений, которая их поддерживает.
(2) Сама инфраструктура обмена сообщениями может оставаться независимой от конкретной семантики передаваемых ею сообщений и упора, который она делает на предупреждение атак, относящихся к связи, и атак на аутентичность конечных точек обмена сообщениями.
В одном варианте осуществления, стек безопасности состоит из нескольких разных уровней обработки, которые описаны ниже. В одном варианте осуществления системы и способы согласования услуг, описанные в заявке '551, можно использовать для обеспечения некоторых или всех операций стека безопасности.
Аутентификация
В одном варианте осуществления, конечные точки обмена сообщениями можно аутентифицировать. Аутентификация это процесс, в котором данная конечная точка демонстрирует другой, что ей дано действительное имя органом, которому доверено делать это. Опорная конечная точка в транзакции должна доверять органу присвоения имен; установление такого органа обычно осуществляется организациями, применяющими доверенную технологию.
Общий механизм для демонстрации обладания действительного имени использует криптографию открытого ключа и цифровые подписи. Согласно этому подходу сущность снабжается тремя фрагментами информации:
(1) различимое имя, которое обеспечивает идентификатор сущности;
(2) пара асимметричных ключей, состоящая из открытого ключа и секретного личного ключа; и (3) сертификат, снабженный цифровой подписью, который утверждает, что держателю секретного ключа дано различимое имя.
Сертификат связывает различимое имя и секретный ключ. Сущности, которая использует секретный ключ для подписывания фрагмента информации, доверено иметь данное различимое имя. Подпись можно проверить с использованием только открытого ключа. Например, аутентификация может производиться на основании стандарта Χ.509ν3.
Поскольку в одном варианте осуществления сущности, которая может продемонстрировать обладание сертифицированным секретным ключом, доверено иметь различимое имя, указанное в сертификате, защита секретного ключа, используемого для подписывания информации, приобретает особую важность. Таким образом, возможность использования личного ключа для подписывания задает границы сущности, идентифицируемой различимым именем. На уровне приложений отправители и получатели должны знать, что сообщения отправлены доверенными сторонами. Поэтому, в одном варианте осуществления важно, чтобы логика уровня приложений сама была частью аутентифицированной сущности. По этой причине в одном варианте осуществления стек безопасности и уровни приложений, которые опираются
- 105 012918 на него, предпочтительно заключены в границу доверия, в связи с чем предполагается, что подсистема, содержащаяся в границе доверия, обобществляет доступ к личному ключу подписывания сообщений сущности.
Авторизация
Вышеописанный механизм аутентификации доказывает распределенным конечным точкам обмена сообщениями, что идентичность их корреспондента заслуживает доверия. Во многих вариантах осуществления эта информация является слишком грубой - более подробная информация о возможностях и свойствах конечных точек может потребоваться для принятия политических решений в отношении определенных транзакций. Например, в контексте фиг. 38, клиенту представления контента может понадобиться знать, не только, что он осуществляет связь с аутентифицированной конечной точкой, но также, осуществляет ли он связь со службой, которая считается уполномоченной обеспечивать действительные объекты «лицензия» ΌΚΜ.
Варианты осуществления стека безопасности обеспечивают механизм для объявления, переноса и применения политики, который основан на более дифференцируемых атрибутах аутентифицированных сущностей, посредством механизма авторизации. С использованием этого механизма, сущностям, которые уже обладают мандатом аутентификации, присваиваются утверждения ролей, которые связывают именованное множество возможностей с различимым именем сущности. Например, имена ролей можно задавать для клиента ΌΚΜ и сервера лицензий ΌΚΜ.
Именованные роли призваны переносить конкретные возможности, которыми владеет сущность. На практике, роли можно присоединять к сущности, объявляя связь между различимым именем сущности и именем роли. Как и сертификаты аутентификации, которые связывают ключи с различимыми именами, в одном варианте осуществления, объявления ролей, используемые для авторизации, подписываются доверенным органом объявления роли, который может отличаться от генератора имен. Внутри сущности, объявления ролей проверяются совместно с мандатом аутентификации как условие предоставления доступа к уровню приложений конечной точки обмена сообщениями.
Сущность может носить столько атрибутов роли, сколько необходимо для построения приложения. Пример, показанный на фиг. 40, демонстрирует сущность с множественными ролями: одной ролью, которая указывает способность функционировать в качестве клиента ΌΚΜ, и двумя служебными ролями. Например, одна сущность может быть одновременно клиентом ΌΚΜ, поставщиком объектов ΌΚΜ и поставщиком данных безопасности. В одном варианте осуществления, 8ΛΜΡ 1.1 используется для объявлений, касающихся атрибутов сущности.
Защита сообщений
Нижним уровнем стека безопасности является уровень защиты сообщений, который обеспечивает целостность, конфиденциальность и актуальность защиты сообщений, и снижает риск атак на канал связи, например, атак ретрансляции. На уровне защиты сообщений:
сообщения между процессами уровня приложений подписываются с использованием личного ключа подписывания сообщений сущности, что обеспечивает защиту целостности и устойчивость к атакам перехватчика;
сообщения шифруются с использованием открытого ключа, которым владеет сущность-адресат. Это гарантирует, что непредназначенные получатели не могут читать сообщения, перехваченные при переносе;
в сообщение добавляются примечания и метки времени, обеспечивающие иммунитет к атакам ретрансляции и облегчающие испытания на живучесть между конечными точками обмена сообщениями;
Используются метки времени сервера для обновления доверенного времени механизма ΌΚΜ.
В одном иллюстративном варианте осуществления, предусмотрена поддержка симметричного шифрования АЕ8, криптографии открытого ключа К8А, дайджестов подписи 8НА-256, и механизмов для сигнализации других алгоритмов в сообщениях.
15. Протокол автозагрузки.
В некоторых вариантах осуществления протокол автозагрузки используется для доставки начальных конфиденциальных данных конфигурации на сущности, например, устройства и программные клиенты. Например, когда сущность желает войти в более крупную сеть или систему и осуществлять связь с другими сущностями с использованием криптографических протоколов, может потребоваться конфигурирование ее персонализованными данными, включающими в себя набор ключей (совместного пользования, секретного и открытого). Когда для невозможно или непрактично предварительно конфигурировать сущности персонализованными данными, ей приходится самозагружаться с использованием криптографического протокола.
Описанный ниже иллюстративный протокол использует секрет совместного пользования в качестве основания для автозагрузки сущности с набором ключей и другими данными конфигурации. В нижеследующих разделах будет использоваться следующая система обозначений:
Е(К, Ό) - шифрование некоторых данных Ό ключом К;
Ό(Κ, Ό) - дешифрование некоторых зашифрованных данных Ό ключом К;
8(К, Ό) - подпись некоторых данных Ό ключом К. Это может быть подпись открытым ключом или
- 106 012918
ΜАС.
Η(Ό) - дайджест сообщения для данных Ό.
У(К, Ό) - проверка подписи на некоторых данных Ό ключом К. Это может быть проверка подписи открытым ключом или ΜАС.
СейСйат(К) - цепь сертификатов, связанная с открытым ключом К. Значение К включено в первый сертификат цепи.
Сег1УепГу(Воо1Сег1 СейСЬат) - проверка того, что цепь сертификатов СейСЬат (включающая в себя открытый ключ, найденный в первом сертификате цепи) действительна под корневым сертификатом Коо1Сей.
А | В | С | ... - последовательность байтов, полученная связыванием отдельных последовательностей байтов А, В, С,....
СЫ(А) - каноническая последовательность байтов для А.
ί.'Ν (А, В, С,...) - каноническая последовательность байтов для сложных полей А, В, С ....
15.1. Начальное состояние.
15.1.1. Клиент.
В одном варианте осуществления клиент имеет следующий набор жетонов автозагрузки (заранее загруженных во время изготовления и/или в программно-аппаратном/программном обеспечении).
Один или несколько сертификатов, предназначенных только для чтения, которые являются корнем доверия для процесса автозагрузки: Воо1Воо1СегЦПса1е.
Один или несколько секретных ключей аутентификации автозагрузки: ВАК (совместного пользования).
Необязательный секретный ключ генерации порождающего числа автозагрузки (уникальный для каждого клиента) В8СК. Если клиент имеет хороший источник случайных данных, это порождающее число не нужно.
Некоторая информация С1^еиίIηίо^таΐ^ои, которую клиент должен передать службе автозагрузки для получения своего ключа конфиденциальности (например, С1^еиΐIηίо^таΐ^ои может включать в себя серийный номер устройства, имя изготовителя и т.д.). Эта информация состоит из списка атрибутов. Каждый атрибут является парой (имя, значение).
Клиент можно конфигурировать множественными сертификатами Воо1Еоо1СегЦПса1е и ключами аутентификации ВАК, чтобы он имел возможность участвовать в протоколе загрузки с различными серверами загрузки, которые могут требовать разных доверенных доменов.
15.1.2. Сервер.
В одном варианте осуществления сервер имеет следующие жетоны:
по меньшей мере один из ключей аутентификации автозагрузки клиента: ВАК (секрет совместного пользования);
пара открытого/секретного ключей, используемая для подписи: (Ек,Эк);
цепь сертификатов 8егуегСегЦПса1еС11ат = СепСЬат(Ек), которая действительна под одним из корневых сертификатов: Воо1Воо1СегНПса1е;
пара открытого/секретного ключей, используемая для шифрования: (Ее/Эе).
15.2. Описание протокола.
Иллюстративный вариант осуществления протокола автозагрузки показан на фиг. 41 и описан ниже. Неудача при выполнении процесса (например, при проверке подписи или цепи сертификатов) приведет к ошибке и остановке выполнения протокола.
Вооΐκΐ^арКе^иеκΐΜеκκаде.
Клиент передает на сервер запрос, указывающий, что он хочет инициировать сеанс автозагрузки, и обеспечивает некоторые начальные параметры (например, версию протокола, профиль и т.д.), а также ГО сеанса (для предотвращения атак ретрансляции) и список доверенных доменов, в которых он может участвовать. В нижеследующей таблице показан иллюстративный формат для Вооΐ8ΐ^арКе^иеκΐΜеκκаде:
| Имя | Воох.511гарВедиея^Ме везде | |||
| Атрибуты | Имя | Описание | ||
| Рго£осо1 | Символическое имя протокола | |||
| Уегахоп | Версия протокола | |||
| Рго£11е | Имя профиля для этих протокола/версии | |||
| Направление | Клиент -> Сервер | |||
| Полезная нагрузка | ВооЪзίгарйедиезϋ | |||
| Имя | Тип | Описание | ||
| Зезз1оп1с1 | Строка | Уникальный Ю сеанса, выбранный клиентом | ||
| ТгизЕОотахпз | Список строк | Имена всех доверенных доменов, в которых клиент может участвовать | ||
| Предполагаемый ответ | Сйа11епдеКедиез1;Меззаде |
- 107 012918
Атрибуты Рго1осо1 и Уегкюп сообщения указывают, какую спецификацию протокола использует клиент, и поле РгоГПе идентифицирует заранее заданный набор криптографических протоколов и форматов кодирования, используемый для обмена сообщениями и данными.
Клиент выбирает ЗеккюпШ, который должен быть уникальным для этого клиента и не подлежит повторному использованию. Например, для генерации уникального ГО сеанса можно использовать уникальный ГО для клиента и значение возрастающего счетчика.
В одном варианте осуществления клиент также передает список всех доверенных доменов, для которых он был сконфигурирован.
В одном варианте осуществления, сервер принимает Воо181гарГес.|ие81Ме88аде и осуществляет следующие этапы:
Проверяет, поддерживает ли он указанные Рго1осо1, Уегкюп и Ргой1е, запрошенные клиентом.
Генерирует Бопсе (строго случайное число).
В необязательном порядке генерирует Соок1е для переноса информации например, метки времени, жетона сеанса или любой другой информации со стороны сервера, которая будет сохраняться на протяжении сеанса. Значение куки имеет смысл только для сервера, и рассматривается клиентом как непрозрачный блок данных.
Извлекает значение ЗеккюпШ из Воо181гарКециек1Ме88аде.
Генерирует вызов: СНа11епде = [Бопсе, Ее, СооИе, ЗеккюпШ].
Вычисляет З (Όκ, СНа11епде) для подписывания вызова с помощью Όκ.
Строит СНа11епдеРес.|ие81Ме88аде и передает его обратно на клиент в порядке ответа.
СНа11епдеРес.|ие81Ме88аде.
В нижеследующей таблице показан иллюстративный формат для СНа11епдеРес.|ие81Ме88аде:
| Имя | СБаИепдеКедиезСМеззаде | |
| Направление | Сервер •Э Клиент | |
| Полезная нагрузка | СЪаЫепде | |
| Имя | Тип | Описание |
| йолсе | Последовательность байтов | Случайный ноне, генерируемый сервером |
| ЗегуегЕпсг урЫопкеу | Последовательность байтов | Закодированный открытый ключ Ее, используемый для шифрования полезной нагрузки сообщения |
| Соокхе | Последовательность байтов | Непрозрачные данные, генерируемые сервером |
| ЗеззюпШ | Строка | 10 сеанса, генерируемый клиентом |
| ЗхдпаЪиге | Последовательность байтов | Закодированная цифровая подпись 5 ί Оз, СН(СЬа11епде)} канонической последовательности байтов вызова Салоп (СКаИепде) = СК(СИ(Копсе), 0Ν(ЗегуесЕпсгурЬхопКеу)> СК(Соокхе), 0Ν (5ез&1оп1с])) |
| ЗегуегСегГз-схса £еСЬа1п | ||
| Имя | Тип | Описание |
| ТгизТОота^п | Строка | Доверенный домен, в котором цепь сертификатов действительная |
| Сег£1£1са£ез | Список последовательностей байтов | Список закодированных сертификатов, образующих цепы СегЪСЬа1п (Ез). Первый сертификат в массиве сертифицирует открытый КЛЮЧ Е5, и каждый из последующих сертификатов, в свою очередь, сертифицирует открытый ключ предыдущего сертификата. Последний сертификат в массиве имеет открытый ключ, сертифицированный корневым сертификатом СА для доверенного домена |
| В ответ на | ВооБзегарКедиезШеззаде |
- 108 012918
В одном варианте осуществления, получив Сйа11еηдеΚе^иезΐΜеззаде, клиент осуществляет следующие этапы.
Удостоверяется, что цепь сертификатов 8ег\'егСегНПса1еС11ат действительная под корневым сертификатом Воо1Иоо1СегНПса1е: Се^ιУе^^П(ВооΐΚооΐСе^ι^П^саΐе, 8егуегСегНПса1еС11ат).
Извлекает открытый ключ Ез из 8егуегСегНПса1еС11ат.
Проверяет подпись вызова: У(Ез, С1а11епде).
Проверяет, совпадает ли 8еззюп1б с идентификатором сеанса, выбранным для сеанса при отправке Воо1Иес.|иез1Меззаде.
Строит С11а11епдеИезропзеМеззаде и передает его на сервер. С11а11епдеИезропзеМеззаде.
Для генерации СНаПепдеИезропзеМеззаде клиент осуществляет следующие этапы.
Генерирует сеансовый ключ δΚ с использованием одного из следующих методов: прямого, с использованием защищенного генератора случайных ключей;
косвенного, с использованием №псе и Вδ6Κ: вычисляет №К = Н (ΈδΟΚ | №псе), и задает δΚ = первые N байтов из №К;
генерирует объект Сйа11епдеΚерзопзе, который содержит [С1а11епде, СйепИнГогтабоп, δезз^опΚеу]. Здесь, С1а11епде входит в состав ранее принятого Сйа11епдеΚе^иезΐΜеззаде, где δе^νе^Епс^урί^опΚеу опущен;
вычисляет δ (ВАК, СНаПепдеИезропзе) для подписывания ответа с помощью ВАК;
шифрует подписанный СНаПепдеИеропзе с помощью δΚ: Е (δΚ, [Сйа11епдеΚезропзе, δ(ВАК, С1а11епдеИезропзе)|);
шифрует δезз^опΚеу открытым ключом сервера Ее. строит СНаПепдеИезропзеМеззаде и передает его на сервер_________________________
| Имя | СЬаПепвеКезропзеМеззаее | |||
| Направление | Клиент Сервер | |||
| Полезная нагрузка | 8е551опКеу (зашифрованный с помощью Ее] | |||
| Имя | Тип | Описание | ||
| 5ез51опКеу | Последовательность байтов | Закодированный сеансовый ключ 8К, зашифрованный открытым ключом сервера Ее | ||
| СЬаЛеп^еЯезропхе [зашифрованный с помощью $К] | ||||
| Имя | Тип | Описание | ||
| СЬа11еп§е | Объект | СКаПел^е | ||
| Имя | Тип | Описание | ||
| Иопсе | Последова- тельность байтов | Случайный ноне, генерируемый сервером | ||
| Соок5е | Последовательность байтов | Непрозрачные данные, генерируемые сервером | ||
| ЗеззюпМ | Строка | Уникальный ГО сеанса | ||
| СйепТ1лГогта1]оп | Массив атрибутов | Массив из 0 или более объектов «атрибут»: Айгйяйе | ||
| Имя | Тип I Описание | |||
| Иаше | Строка | Имя атрибута | ||
| Уайте | Строка | Значение атрибута | ||
| ЗеззюпКеу | Последовательность байтов | Закодированное значение секретного сеансового ключа ЗК | ||
| 81§паТиге | Последовательность байтов | Закодированная цифровая подпись 8(ВАК, СИ(СЬаНеп£еКе$роп5е)) канонической последовательности байтов СИ(СЬа11епаеКе5роп5е) = СХСТЦСНаПепре), ΟΝ(01ϊβηΐΙηΓοππ3ΐίοη), СКфеззюпКеу)) | ||
| Предполагаемый ответ | Воо1з1гар&£5ропзеМезда£е |
- 109 012918
Сервер принимает Воо181гарСйа11спдсКс8роп8с и осуществляет следующие этапы:
дешифрует сеансовый ключ 8Κ с использованием своего секретного ключа Рс: Р(Рс, 8с88^оиΚсу);
дешифрует Сйа11спдсКс8роп8с сеансовым ключом 8Κ, полученным на предыдущем этапе: Ρ(8Κ, С11а11спдс);
проверяет подпись вызова: V(ΒАΚ, СйаПспдсКскропкс);
проверяет, совпадает ли сеансовый ключ 8Κ с ключом, используемым для дешифрования; проверяет, при необходимости, значения Соокю и №псс (например, метку времени);
проверяет, совпадает ли Зскыопй с идентификатором сеанса, выбранным для сеанса при отправке ΒооΐКс^ис8ΐΜс88адс;
строит Βооΐ8ΐ^арКс8роη8сΜс88адс и предает его на клиент.
Βооΐ8ΐ^арКс8роη8сΜс88адс.
Для генерации Βооΐ8ΐ^арКс8рои8сΜс88адс, сервер осуществляет следующие этапы:
анализирует СНспПиГогтайоп, полученную в Сйа11сидсКс8рои8сΜс88адс и ищет или генерирует данные;
конфигурации клиента, которые нужно передать для этого запроса автозагрузки (они могут включать в себя ключи конфиденциальности (Ес/Рс) для узла, представляющего клиент). Обычно сервер использует значение №псс и Соокю для облегчения извлечения верной информации для клиента.
создает ВооШгарКскропкс с 8с55юпИ и данными конфигурации;
вычисляет 8 (Р§, ВооййарКскропкс) для подписывания Ра1а с помощью Р§;
шифрует подписанный ВооШгарКскроикс сеансовым ключом 8Κ: Ε(8Κ, [Воо181гарКс8рои8с, 8(Р§, Воо181гарКс8рои8с)])
| Имя | Воокз^тарЕезропвеМеззаде | ||
| Направление | Сервер Клиент | ||
| Полезная нагрузка | ВооЬ.зЪгарйееропзе [зашифрованный с помощью ЗК] | ||
| Имя ] Тип | Описание | ||
| ЗеззгопТй | Строка | ГО сеанса | |
| ОаИа | Последовательность байтов | Данные конфигурации для клиента | |
| 5±дпагиге | Подпись | Цифровая подпись 5 (Оз г СМ (ВооЪзЪгарВезропзе) ) канонической последовательности байтов СМ (Воо1:з1:гарВезропзе) = СИ (СИ (5езз1оп! ϋ), СЫ(Оа£.а)) | |
| В ответ на | СЬаНепдеКе^ропгеМеззаде |
15.3. Доверенные домены.
В одном варианте осуществления каждый доверенный домен включает в себя орган корневого сертификата и уникальное имя домена. Когда клиент передает ВооШгарКсдисЦ, он идентифицирует все доверенные домены, которые он желает принимать (т.е. сертификаты которых он будет считать действительными). Сервер выбирает доверенный домен из списка, переданного клиентом, если он поддерживает хотя бы один из них.
15.4. Подписи.
В одном варианте осуществления всякий раз при использовании подписей в полезной нагрузке сообщений, подписи вычисляются на канонической последовательности байтов для полей данных, содержащихся в подписанной(ых) части(ях) сообщения. Каноническая последовательность байтов вычисляется из значений полей, но не из кодировки значений полей. Каждый профиль, предпочтительно, задает алгоритм, используемый для вычисления канонической последовательности байтов полей для каждого типа сообщения.
15.5. Профили.
Профиль протокола автозагрузки это набор вариантов различных криптографических шифров и форматов сериализации. Каждый профиль, предпочтительно, имеет уникальное имя и включает в себя следующие варианты:
алгоритм шифрования открытым ключом;
алгоритм подписи открытым ключом;
алгоритм шифрования секретным ключом;
алгоритм подписи секретным ключом;
кодирование открытым ключом;
алгоритм дайджеста;
каноническая сериализация объекта;
формат сертификата;
минимальный размер нонса;
- 110 012918 маршализация сообщений.
Приложение А
Ниже приведен пример объекта «контроллер» с множественными блокирующими подписями. Примечание: в этом примере ключи контента не шифруются <Соп1го11ег хт1п8=11Ир://\*^¥1у.т1егСги81,сот/Ос1ориа/1.0 И=ит:хос(оризлп1ег1ги8(.сот:соп1го11ег:37 А50262ЕЕЗЗ 89 А14АВС0ВС7ВЕ5Ц43Е5 >
<Соп1го I КеГегепсе>
<14>игп: х-ос1ориз .ί п1е11гиз(.сот χοηίτο 1:0 001 <71 ά>
<ϋί£βϊί>
<131£езгМе11ю<1 хт1пз-Ίιΐίρ:/Λνλννν.Λν3 .ог£/2000/09/хт1(131£#'’
А12Оп1Ит=ЬНр:/луулу.Ю.ог§/2000/09/хгп1(181£#зЙа1 />
<О1дезгУа1ие хт1п5=Ийр:7/ш\уте.а/3.ог£/2000/09/хтк1з1£#и>) ζ95η 10У7СВ1К8/гЗф4ХуКу2п11А=</та§е51Уа1ие> </О|§ез1>
</Соп(го1К.е1егепсе>
<Соп! го 11 ©<1Тагде1з>
<Сотеп1КеуКе!егепсе>
<И>цт :χ-οοΐοριΐ8.ί п1егЩ|ЗГ.сот: контеят-кеу:2001</1 ά>
</СогйепЖеу КеЕегепсе>
<Соп1е пЖеу Ке Гегепсе>
<14>иш: χ-οοίοριίϊ.ί п(ег1п15Г.сот жонте нт-кеу :2002</14>
</Соп4епЖеуКеГегепсе>
<Соп1е ηίΚ еу КеГегепсе>
<14>ит: х-ос1орив .ί п(ейпш.сот :конте нт-кеу :2003<71 0>
</Со п:епЖеуКеГегепсе>
</Со ηΐτοί 1е0Таг§е18>
</СопГю11ег>
<5ΐ£па!игс И=81§па1игс.0 хшIпз=Ьйр://ννχνν»·.уу3.ог§/2000/09/хппИ8ί <8|£пе(Ппй>>
<Сапотса1 ί гайопМеОюс! А1§опЙ1т= Ьйр :/7ул<лулуЗ .огд/2001/10/хт 1-ехс-с 14п#” />
<8|§па!игеМегИо(1 А1§оп1Ьт-Ъ«р:/Лучту.уу3.ог§/2000/097хт1с181§#Г15а-811а1 !>
<К.еРегепсе Е1М=иго: х-ос1ор ιιβ. ίη! ег4гиз( .со т :со п1го11 ег: 37 А50262ЕЕ3 389А14 АВ СОВ С 7В Ε5ϋ43 Е5 > <ТгапзГоп11з>
<Тгапзй>гт А1§огйЬш='Ъйр ;//у»л¥тл,.1п(еПгиз1.сот,/ОсГори5/хт1с1з1§#сЬ5-1_0 ί>
</Тгапз1огт8>
<О1£е8ГМе11юс1 А1§опгИт=кир://улуулЮ.огд/2000/09/хт1<1з1£#811аГ />
<О1§е81Уа1ие>61 ζΧΡ93ζ7ζΟννΗ6Μ8Ρ т 0ОЬОС?схик=</О1£ез1У а!ие>
</Ке£егепсе>
</8щпе<Пп(о>
<31£па1игеУа1ие>пуоу\У+\у2391гО(3(Ъа4с,\УТО1К1пЬРидЕииЗХ977МООр™иО02Г(1зА1СУ]Ас\у714пГ\¥иУ1 а\¥\¥/с1р2¥Р7рзГеЬЕ5СуигНи8ЕаК.1/ЕУЬОкр\У1¥х11/ЫЕр4гЗуК9ки50Аи5а4ВОхОх9Е7пи4чи9УМрп)А7Е ΟριιχάΡβΖΙΜ 1 ууКдМ>рТк94=<81£па1иге V а1ие>
<Кеу1пй» <Х509БаГа>
<Х509СеП|Лса1с>М11С63ССЛ1ОгЛ«ТВАё1ВВ.|АМВ|;кч11к1С9уу0ВА0иГЛОСВ5гЕкМЛкСЛ1кЕВЬМС\;\г МхЕгАКВ2МУВА8ТСкМ1ЬС1тЬ31иа^ЕхРОА8В8КУВАсТС]РЛ1ЬпКМЕМзУХ1ЬМ8А\¥НёУОУ9РКЕха1Ь пРВспКус!ХН01РК1У2ИиЬ2ху2211сгЕиА®1СА1СБС.хМЬТ2^ЬЗВ1суВЕик0х(ЗОЛ\\'В&\УВЛМТО09]сЮ9 ^ХМ£У6Уг4СВ1>9ТЕпМСиОС8чС5торЕ1АК¥¥Ь2МОЬЗВ1су102Х№Е\УМК>ОЬ¥с1ХМиЬтУОМВ4 ХОТАОМГХ2ч'ООАу/МТиуОУоХОТАОМОиууООАу/МТиуОУо\удсЕхСгА1В§К\'ВАУТА1УТМЕМ\уЕ9У [)УС>01ЕгурЕ\\У'хр2т9уЬт11-1МК9лЕ8¥ОУСС>НЕи1ТУ\\'50У5ВОЬС1;уУ'ГЕдМВ4С;А1иЕСНМХ8\У507Х 10οηνζΛΓΒυΖν/Ν<Λ™93624ρΖΧΜχΡηΑδΒ§ΝνΒΑ8ΤΓ09]469ννάΧΜ£ΕΡΙΝΜΒ8\νΗ9ΥθνθρθΕχΖΡΥ3ΚΛ’ сНУ74ЕК1сЗр8Тт9к25АууМОАхУ154ууЕАУЖо21ЬусУАРкВГ119у¥ЗКусШ'ЖХКкЗО(Ьт9к280луМЕАх<9 ОЬ\ус1ХМиЬтУ0М1С1МА0СС8яС181ЬЗОС)ЕВЛ(9иАА4ОЕ:АОСВ|0КВ«,0Ои8А.10Аг781УТи«ЕО21Му5зС1 йпгЕСу1]А0уЬё(2с+сРХрГе1<1АС|СЫ п1ет1/гЫи7гаК^Оео1 γ18εΚ57Ρχν+ζΗΨ14Ρ 1,ϊηη8/ΙΚΕ084Κ01βοΜίΟ Т11КЕгЬ2пиЗхТОКС£Х£ЕХЕАЬ^АУпЕХ7Нру/'1Ьо2тТт1Ь£к5ХУоРгРу/ЗхМРСУуЯОА<2АВМАООС8ч<331ЬЗ О0ЕВВСиАА4ОВАБ1гНЗгХсСкРпкУЫ52скбПУзН1КР+/1НгСиТ<ЗКеЬ6+12гЕкб81ХиУ/ХЕО1О1оРЕМае7 ХШдрОМкЬ64хоРоШ|К9У4®з1]у9р8!исеаМ1ХУУ/ч+Х1М(17Н1В1ч25ХчВ8с89/КАКККлтаККкрНЕУЗи ВАВуЕ8СЯК51Н9ЬРиУгЪЗеУпе</Х509СегГ1Йса1е>
- 111 012918 <Х509Оага>
</Кеу!п£о>
<7$и§па1иге>
<81§па1иге хт1п8=11йр://упуууллг3.ог§/2000/09/хт1(|51§#>
<81§пес11п1о>
<СапошсаНга1юпМе11ю<1 А1§оп(11т=Кйр://’,ллУ1Л'.у.'3.ог§/2001/10/хт1-ехс-с14п# />
<81§пашгеМе1Ьо(1 А1§огйКт=ййр:/ЛукУЧ\уу3.ог§/2000/09/хгп1с1з1§#1|тас-811а1 />
<Ке£егепсе иК1=#81§па1иге.0''>
<01§ев1МеОю6 А1§огй11т-’Ьйр:/Лууужг¥3.ог§/2000/09/хп11<1з1§#511аГ />
<ΏΪ8« 1Уа1 ие> ΑςΡ V Οη νΝϊ/νο511 сМу К 1η§ΟΝΚΐΜ=</ϋϊ§65ΐν а! ие>
</В.е£егепсе>
<Ке£егепсе ЦК1=иП1:х-ос1оризл1йег1гиз1.со1п:сопйо11ег;37А50262ЕЕ3389А14АВС0ВС7ВЕ5В43Е5> <Тгапз£огт8>
<Тгапз£огт А1§ог1(Ьт=’Ъйр :/Λνν™ лп1ейгавЬ«>т/Ос1ори5/хтШ$1ё#сЬ5-10 />
</Тгапз£огтз>
<01£еЯМе(Иос1 А!§оп1Ит=кйр;//у1^лу.\у3.ог§/2000/09/хт1сЫ§#з11а1 1>
<01§ез1Уа1ие>61ζΧΓ98ζ/ζΕ\νΗ6Μ3ΓιηΟΟΐ·0<2οχι±=</Οί§ε5ΐν а1ие>
</Ке£егепсё>
</81§пе(11п£о>
<81§пашгеУ а!ие>ТсКВ ϊΖ2γ+Υ р34оОкИ62 ίΤίΥ+ηίΟ=</81£па1иге V а1ие>
<Кеу1п£о>
<КеуМате>игп:х-ос1ори5.1п»ейгий.сот:5есге!-кеу:2001 </КеуКате>
</Кеу1п(о>
</81§паШге>
<51§па1иге хт1пз-Ъйр://илу\улу3 .θΓ§/2000/09/χηι1ά5ί§#>
<8ί§ηβ<1!η£ο>
<Сапотса112а(юпМе11ю<1 ΑΙ§οπΐ1ιηι=Ιιηρ:/Λννννν.νν3 .ог§/2001/10/хт(-ехос 14п# />
<8ΐ§η агигеМе! Ьо<1 А1§огй1ип-Ъйр :/Луулу. ууЗ .ог§/2000/09/хт16з1§#1ш1ас-з Ьа 1 !>
<Ке£егепсе ЦК1=’'#0>
<О1§ез<Мс1Ио4 А1§ог1Й1т=кйр://ууууУ1'.уу3.огд/2000/09/хт1с1з1§#811аГ' />
<Πί§ез(У а 1ме> АцР УОп νΝ) /νο 511 сМу Κ 1η§ΟΝΚίΜ=<Πί §ез1Уа1ие>
</К.е(егспсс>
<КеГегепсе иК1=ит:х-осЮриз.1п(еПгиЯ.со1п:соп1го11ег:37А502б2ЕЕ3389А14АВС0ВС7ВЕ5П43Е5> <Тгапз£огтз>
<ТгапзГогт А1§оп1Ьт=Ьйр://х™л|Улп1ег1ги8Есоп1/ОсГориз/хт1йз1§#сЬз-1_0 />
</Тгапз£огт5>
<01§ез(Ме(Ио6 А1§огййт=11«р://и^уу;.у/3.ог§/2000/09/хт1(1з1§#з11аГ' />
<01§ез(У а1ие> 01 гХГ98г/гС\уН6МаР тООЬ Офсхик=</О18ез1 V а1 ие>
</Ке£егепсе>
</81§пе<11п£о>
<8|§пагигеУак1е>яАипррХС 18к18Уео8ЦНЬсХТяНСА=</8|§па1ъгеУа1ие>
<Кеу1п£о>
<КеуМатё> иго :х-ос(ориз. ϊ гйейгий.со т: кесгейкеу :2002</К еу№т е>
</Кеу1п£о>
</8щпа111ге>
<8|§па1иге хт1пз=ййр://йгулу,уу3 ,ог§/200!}/09/хтМ51§#>
<8|§пе(11п£о>
<Сапоп1са112абопМе1Вос| А1§опЙ1т=11Йр://ууууту.уу3.ог§/2001/10/хт1-ехс-с14п# />
<81§па1игеМеЙЮ(1 А1§ог1(Ьт=Ьйр://«моу.уу3.ог§/2000/09/хт1<151§#11тас-8Иа1 /> <Ве£егепсе ЦК1=#0>
<ϋΐ^&3ίΜβίΗοά А1§оп1кт=''кйр://уу\ууу.и'3.ог§/2000/09/хтМ51§#811а1 />
<О1§езгУа1ие>АяРУ0п¥11|/ус511сМуК1п§СМК1М=</О1§ез1Уа1ие>
<УКеГегепсе>
<К.е1егепсе иК1=игп:х-ос1оризлп1е11п181.сот:согйго11ег:37А50262ЕЕ3389А14АВС0ВС7ВЕ5О43Е5> <ТгапзГогтя>
<Ггап8 £огт АI §огйк т= Ьйр://уууууу. ί п1егйиз(.сот/Ойориз/хт И 8 ί §#с Ьз-1 0 />
</Тгап8£огтз>
<0|§е51МеЙ10<1 А1§оп01т=Ьйр://уу\ууу.уу3.ог§/2000/09/хт1(1з1д#8ЪаГ' />
<ϋ 1§ез( Уа1ие>612ХР98г/гСлуН6МаГтООЬОС)схик=<ЛЯ§е51У а! ие>
</Ке£егепсе>
<8ί§ηβάΙη£ο>
<8 ί§η ашге \'а1ие>ЬКхЬ8М8 2(14ΚΧ¥5Υζ6ιι1ιΒχζ1 ίϊθο=<81§па1иге Уа1 ие>
<Кеу!п£о>
<КеуНате>игп:х-ос1ориз.т1ег1ги8Г.согп:зесге(-кеу:2()03</Кеу№гпе>
</Кеу1п£о>
<78|§па1иге>
</Вип41е>
- 112 012918
Приложение В
В этом приложении В представлено ΧΜΕ-кодирование объектов в одном варианте осуществления системы с использованием иллюстративного механизма ΌΡΜ Ос!орик, описанного здесь в другом месте. Для конкретного приложения, можно создать схему ΧΜΕ, зависящую от приложения, путем импорта схемы ΧΜΕ, показанной ниже (Ос!орик ХЫЬ 8сЬеша) и добавления элементов, зависящих от приложения (например, расширений, используемых для отмены). В одном варианте осуществления, кодировка объектов в ΧΜΕ должна быть способно проходить удостоверение согласно схеме ΧΜΕ, зависящей от приложения. Дополнительные возможные ограничения на эти ΧΜΕ-кодировки представлены ниже.
В примере, представленном в этом приложении В, базовым типом схемы ΧΜΕ для всех объектов ΏΕΜ является Ос1орикОЪ]ес1Туре. Это означает, что все объекты поддерживают атрибуты и расширения. Тип каждого элемента объекта ОсЮрик является производным этого базового типа. Эти типы могут группировать другие элементы, например, элемент 8есге1Кеу для Соп!еп!КеуТуре.
В этом иллюстративном варианте осуществления ключи системы распространения ключей 8сиЬа описаны применительно к исключению: элемент 8сиЬаКеук является дочерним по отношению к элементу расширения. То же самое касается ключей отмены с расширением Тогребо.
Как описано здесь в другом месте, существуют разные виды объектов ОсЮрик (например, Соп1еп1Кеу, Рго1ес1ог, Соп!го11ег, Соп!го1, Кобе и Ыпк). Эти объекты можно связывать друг с другом совместно с расширениями с использованием элемента <Випб1е>. В одном варианте осуществления, если объекты или расширения подписаны в <Випб1е>, то <Випб1е> содержит элементы <81дпа1иге>, описанные здесь в другом месте.
Схема ΧΜΕ ОсЮрик (Ос!орик.хкб):
<?версия хт! -Ί.0 кодировка=иТР-8?>
<х5:$сЬета Мг^Иатезрам-Ъйр://т1е1Ш8(.сот/Ос1ориз/1.0 хп11п5='’Ьнр://1п1ег1гиз1.сот/Ос1ориз/1.0 хт1пз:хз='ЪКр;//члч\¥.'Л'3.ог&'2001/ХМЬ8сйета хт1пз:с15=11Гф://,т¥\¥.^З.ог^2000/09/хгп1(1з18# хт1пз:хспс=Кир://у>л™.«3.ог&'2и01/04/х1п1спс# с1степ1РогтОсГаи11=''чиа11йе(1 айг|Ьи1еРогп1Оейи11=ипяиаЛЯе(1>
<!-- импорта!
- 113 012918 <хз: (троп патезрасе-1 кйр :/Λν\ν\ν.ν/З ,ог§/2000/09/хт1(1з ΐ§£ зсЬетаЬосаО οη= хт1с1з1 §-соге5скета.хз<Г'/>
<хзлтроп патезрасе- ιΗΙίρ://\ν\ν\ν.τν3.θΓ§/2001/04/хт1елс# зсЬетаЕосаЕоп='гхелс· зскета.хмГ/>
<!-- элементы верхнего уровня —>
<хз:е1степ1 пате- ’Коо1Ъс?е!ОЬ)есг 1урс=''Коо1ЬеуеЮЬ)сс(Туре аЬз|гас<=Щ1е”>
<хз:е1етеп1 пате=Ос1оризОЬ)есГ' Зуре=Ос1оризОЬ)есгТуре аЬзГгас1=’Чгие',/>
<!-- базовый элемент -->
<хз:е1етеп4 пате=Випб!е 1уре=Вигк11еТуре/>
<хз:е!етеп1 пате-'Ыпк 1уре-’ЪткТуре зиЬ51|1и11опСгоир=К.оо1ЬеуеЮЬ]ес1/>
<хз:е1етеп1 лате=Но<1е 1урс~Мо4еТуре зиЬз11Ш(юпОгоир=Воо(Ьсуе10Ь|ес(7>
<хз:е!етеп1 пате-'СоШгоГ 1уре=Соп1го1Туре зиЪз11й(юпСгоир=”Ноо1Ьеуе101уес1/>
<хз:е1етет пате=Соп1го11ег 1уре=”Соп(го11егТуре знЬз1Ш10пСгоир=Коо1Ьеуе!ОЬ)ес1> <х5:е1етеп1 пате=Рго1есЮг 1уре=Рго1ес(огТуреф' зиЬзкШНопСгоир=Коо1Ееуе1ОЬ)есГ/> <хз:е1етеп( пате-'СотепЖеу 1уре-Соп1ег>1КеуТуре
5иЬз111и(юпОго11р=Коо1Ееуе10Ь)ес1/>
<!— элементы ключа —>
<хз:е1етеп( пате=8есгегКеу 1уре=КеуТуре/>
<хз:е!етеп{ пате-'РиЬПсКеу 1уре=Ра1геЖеуТуре'7>
<хз:е1етеп( пате-Рп«а1еКеу 1уре=Ра1геОКеуТуре>
<хз:е1етепг пате=КеуВа(а 1уре=”КеуРа1аТурсЛ' <!— о1йег элементы ->
<хз:е1етепг пате=АПг1ЬигеЬ|3( 1уре=АапЬи(е1лз1Туре/>
<хз:е!етеп1 пате-'АПлЬШе (уре- 'АйпЬи(еТуре’7>
<хз:е1етепЗ па1пе=Ех1епз1О11Е15( 1уре=Ех1епзюпЬк1Туре/>
<хз:е1етеп1 пате=Ех1епзюп 1уре=Ех1епзюпТуреп 5иЬ5111и(1оп<Згоир=ффВоо1Ееуе10Ь1ес(/>
<хз:е1етепЗ пате=ЫпкРгот Зуре=Ос1оризОЬ1ес1Ке1егепсеТуре/>
<хз:е1етеп1 пате-’1лпкТо 1уре=,,Ос(оризОЬ]ес(КеГсгспссТуре/>
<хз;е1етеп( пате-Ίά 1>’ре=пхз:з1г1П§г'/>
<х$:е1етеп1 пате-Όί£β$ί 1уре=ффО1§ез1Туре'ф/>
<хз:е1етепЗ пате=Соп1го1Рго§гагп гуре=Соп1го1Рго«гатТуре/>
>ло.с1к;1пс111 паше- ι^νυ^ινχννιυικ? ν-υΜνινινιιιιι^ в уре <хз:е1етеп( пате=Соп(го1КеГегепсе'’ 1уре=ОсюризОЬ)ес1й.еГегепсеТуре/>
<хз:е1етеп1 пате-'СопсепЖеуКеГегепсе 1уре=,фОсЩризО1уес(К.еГегепсеТуреф7>
<хз:е!етепГ пате-'СотепЖеГегепсе1уре=Ос1оризОЬ]ес(Ке{егепсеТуре’ф/>
<хз:е1етеп1 пате=РгоСес1е(1Тагде1з 1уре=Рго1ес1ес1ТагеекТуре/>
<хз:е1етеп4 пате=Соп(го11ес1Таг§е15 (уре=',Сопй'о11ес1Таг§еЗзТуре/>
<!-- зсиЬа —>
<хз:е1етеп1 пате=8спЬаКеузф| (уре=8сиЬаКеузТуре'7>
<!— базовый тип для объектов ОсЮриз ->
<хз:сотр1ехТуре пате=К.оо4Ьеуе10Ь]ес1Туре7>
<хз:сотр1ехТуре пате=Ос1оризОЬ]ес1Туре>
<хз:сотр1ехСопГепГ>
<хз: ех1епзю η Ьазе= Коо1ЬеуеЮЬ]есгТу ре>
<хз:зечиепсе>
<хз;е!етеп1 геГ=АШтЪи1еЕЬ1 т!пОссигз=0/>
<хз:е1етеп1 ге(=Ех1епз1опЕ1зГ ттОссиге=“0>
</хз:зечиепсе>
<хз:айпЬи1е пате=фЧ<1 1урс=хз:з1г1п§ изе=ор1юпаГ7>
<хз:ех1епз1оп>
<хз :сотр 1ехСоп(еп1>
</хз: сотр I ехТу ре>
<хз:сотр1ехТуре пате=”АпуСоп1атегТуре>
<хз: со тр! ехСоп(еп1>
<хз;ех1епзюп Ьазе=КоогЕеуе1ОЬ)ес1Туре>
<хз:зедиепсе>
<хз:апу ргосеззСол(еп(з-ф1ах'7>
</хз:зедиепсе>
</хз:ех1елзюп>
</хусотр1ехСоп(ел|>
</хз:сотр1ехТуре>
<хз:сотр1ехТуре пате=Ех1епзюпТуре>
<хз:сотр1ехСоп(еп(>
- 114 012918 <хз:ех1епз1оп Ьазе=АпуСоп1атегТуре''>
<хз:зеяиепсе ттОссигз=“0>
<хз:е1етеп1 гс(=О|£сзГ Ш1п0ссигз=0’7> </хз:зечиепсе>
<Х8:аиг1Ьи(е пате-Чд (уре=''хз:япп£ изе=ге(|ийесГ/> <хз:айпЬше патс=зиЬ|сс1 1уре=хз:Япп£/>
<7хз:ех1еп51оп>
</хз:сотр1ехСоп1епР </хз: сотр!ехТуре>
<№: со тр 1ехТу ре пате= Ехгепз юп!ляТуре> <хз:зециепсе>
<Х8:с1стсп( геЕ=Ех1епзюп тахОссиг5=ипЬоип1сй/>
<Лсз:зечиепсе>
<х® :сотр 1ехТуре>
<хз: сотр!ехТуре пате~ Απτί Ьи(е1ТяТуре > <х5Г5едиепсе>
<хз:е1етеп( ге(^”А«пЬи1е тахОссигз-’ипЬоип<1е<1'7>
</χ5:5θηιιβηοβ>
</χε: сотр!ехТуре>
<хз :сотр!ехТуре пате=АипЬиТеТуре >
<хз: з ϊ тр I еСо пГепО <хз:ех1епзюп Ьа8е=''хз:з(гт£> <хз:аПпЬи1е пате=пате 1уре=хз:51пп£ изе=ге(|шге<1'7> <хз:аПпЬи1е пате- '(уре (уре-'хз:Япп£ 4ейи1Т=з1гт§7>
<Ухз:ех1епзюп>
'7хв: δί тр 1еСоп1еп1>
</хз: сотр 1ехТуре>
<хз:сотр!ехТуре пате=О1§еЯТуре”> <х5:8в(]иепсе>
<х5:е1етеп1 ге(=с15:012езТМесИос1’'/>
<х5:е1етепТ ге{=<18:О1§е81 V а1ие/>
</х8:^иепсе>
</хз:сотр!ехТуре>
<хз:со тркхТуре пате= Ос(оризОЬ]ес1Ке1егепсеТуре> <хз:зеяиепсе>
<хз:е1етеп1 геГ=1<Г7>
<хв;е1етеп1 Γβ^’ΌίββϊΓ т1пОссиг5=”0/>
</хз:зеяиепсе>
</хз: сотр! ехТуре>
схзхотркхТуре пате=Рго1ес(е(1Таг§е1зТуре>
<хз:зсциепсе>
<хз:е1етеп1 геТ^Соп(еп(Ке1егепсе тахОссигз=ипЬоипде(1/> <Х8:5ес|иепсе> <хз: со тр I ехТуре> <хк:сотр1ехТуре пате=Соп(го11ебТаг£е1зТуре>
<хз:8е<|иепсе>
<х8:е1етеп( ге£=Соп1еп1КеуКе(егепсе тахОссиг8=ипЬоип(1е<Г,/> </х5:зе(|иепсе>
</хз:сотр1ехТуре>
<!- Тип ВипсИе -->
<хз;сотр!ехТуре пате=Вип<11еТуре>
<хз:зечиепсе>
<хз:е1етеп1 ге(=коо1ЕеуеЮЬ)ес1 тахОссиг5=ипЬоип<1е<Г'л> <хз:е1етем геТ=<1з-.51ёпа1иге ттОссиг5=0 тахОссигз-'ипЬоипйесГЛ· </хз:зециепсе>
</хз:сотр1ехТуре>
<1— Типы Νο4β —>
<х5:сотр1схТуре пате=Мо(1еТуре>
<хз:сотр1ехСоп1еп1>
<хз :ех1епзюп Ьазе=ОйоризОЬ) ес(Туре’7>
</хз: сотр1ехСоп1еп(>
</хз:сотр1ехТ уре>
<!— Типы 1лпк —>
- 115 012918 <хз:со1пр1ехТуре пате='Т|пкТуре'’>
<хз :со тр 1ехСоп(еп(>
<хз:ехкпзюп Ьазе=Ос(ори5ОЬ|ес1Туре'’> <хз:зс<|иепсе>
<хз:е1еше111 ге(=Ь|пкГгот'7>
<хз:е1етеШ геГ='Ъ|пкТо'7>
<хз:е1етеп1 геР=Соп(гоГ' ттОссигз=0/>
<х5:8ечиепсе>
<Ух5:ех(еп51оп>
</хз: сотр!ехС отеп1>
</хз: сотр! ехТуре>
<!-- Типы РгоСесЮг ~>
<х5:сотр1ехТуре пате=Рго(ес£огТуре>
<хз :сотр1ехСоп 1еп1>
<хз:ех1епзюп Ьазе=Ос(ори5ОЬ]ес1Туре> <хз:5«|иепсе>
<хз:е1етеш геР=Соп(еп1КсуКеР:гепсс,’/>
<х5:е1етеп( ге!=Ргогес1ес1Таг§ей/>
</хз:зечиепсе>
</х5:ех(еп81оп>
</х$:сотр1ехСоп1еп1> </хз:сотр1ехТуре> <!- Типы ΟοηΐτοΙ -> <хз :сотр!е хТуре пате_Сос1еМос1 и I еТуре>
<хз;з1тр1еСогйеп1>
<х8:ех1епвюп Ьазе=х8зПт§г'>
<хз:айпЬи(е пате=байт-кодТуре изе=гсчийс<Г7>
</м:ех1еп51оп>
</хз:31тр1еСоп1еп1>
</хз:сотр1ехТуре>
<хз :сотр1ехТуре пате=Соп(го 1Рго£гатТ уре>
<хз:зечиепсе>
<хз:е1етеп( ге(=Со4еМо<1и1е/>
</хз:зециепсе>
<хз:айпЬи(е пате=1уре” изе=гедшге<1'7> </х8:сотр1ехТуре>
<хз:сотр1ехТуре пате-'Соп(го1Туре>
<хз :сотр I ехСоп(еп£>
<Х5:ех1еп51оп Ьаяе=Ос1оризО1уес1Туре'’> <хз:5едиепсе>
<хз:е!етеп1 геб=''Соп(го1Рго§гат/>
</хз:8ечиепсе>
</хз:ех£епзюп>
</х5:сотр1ехСоп1епР· </хз:сотр!ехТуре>
<!— СоМгоПег Туре —>
<хзхотр1ехТуре пате=Сопгго11егТуре>
<хз:сотр!ехСоп(еп(>
<хз:ех1епз1оп Ьазе=Ос(оризОЬ]ес(Туре>
<х8:8едиепсе>
<хз:е1ешеп( геР--Соп1го1К.сГегспсе'7>
<хз:е1етеп1ге(^,,Соп1го11е<1ТагЁе18/>
</х5:8ечиепсе>
</хз:ех1епзюп>
</хз:сотр1ехСоп1еп!>
</хз:сотр1ехТуре>
<!- Типы Кеу —>
<хз:сотр1ехТуре пате=КеуТуре>
<хз:5едиепсе>
<хз;е1етеп1 геЕ',КеуОата'7>
</хз:зсяиепсе>
<хз:аппЬиге пате=]4 (уре-'хз^ггтё изе=геяшгесГ7>
<х8:а11пЬи1е пате=иза^е 1уре=хз:81пп§ изе=необязательный'7>
- 116 012918 <хз:сотр1ехТуре>
<хз:сошр1ехТуре пате=Раиес1КеуТуре>
<хз:сотр1ехСоп1еп1>
<хз:ех1епзюп Ьазе-'КеуТуре>
<Х5:аИпЬиГе пате~рап 1уре=”хз:51г1П£ изс=гсяшгесГ’/>
<хз:ех!епзюп>
</хз:сотр1ехСоп(еп1>
</хз:сотр1ехТуре>
<хз:сотр1ехТуре пате=КеуВа1аТуре т1хеб=(П1е”>
<хз:зеф1епсе>
<хз:е1етеп1 ге(=хспс:Епсгур1ес1Оа1а'’ т1пОссигя_''07>
</хз:зеф1епсе>
<хз:а11пЬи1е пате=епсо<1!п§ иае=гечшгеб>
<хз:$1тр1еТуре>
<хз:гез1пс1юп Ьа$е=ха:з1пне,,>
<хз:епитега(юп уа1ие=хт1спс/>
<хз:спитега(1оп уа1ие=Ьазе647>
<хз:гез(пс{юп>
</хз:з1тр1еТуре>
</хз:айг|Ьи1е>
<хз:а«т1Ьи1е пате='Тогта1 изе=,'гетццге<Г'>
<хз:з1тр1еТуре>
<хз:геМпс1юп Ьазе=хз:зЫп2>
<хз:епшпега£юп уа1ие=РКС5#8/>
<хз:епатегаТ1оп уа1ие=Х.509/>
<хз:епитегайоп ¥а1ие=КАЧ7/>
</хз:гез1п«юп>
</хз:з1тр1еТуре>
</хз:аПпЬн1е>
<хз:сотр1ехТуре>
<!- Типы Соп1еп(Кеу —>
<хз:сотр1ехТуре пате-Соп(етКеуТуре>
<хз:сотр1ехСоп1еп1>
<хз:ех1епзюп Ьазе=’'ОсЮризОЬ)есЕГуре“>
<хз:зечиепсе>
<хз:е1етеш гс(=5есге(Кеу’7>
</хз:зециеп«>
</хз:ех1епзюп>
<Ли:сотр1ехСоп1еп1>
</хз:сотр1ехТуре>
<!- Расширения ЗсиЬа ->
<хз:сотр1ехТуре пате=5сиЬаКеузТуре>
<хз:5еяиепсе>
<хз:е1етеп1 ге!=£есге1К.еу пппОссигз=0 тахОссигз=ипЬоип<1е<1/> <хз:е1етеп1 ге£=РиЬНсКеу ттОссиг5=''0 тахОссигз=ипЬоипс1ей7> <хз:е1етеп1 геЕ’ТпуаГеКеу т1пОссигз=0 тахОссигз=ипЬоип<1е<1> </хз:зециепсе>
</хз:сотр1ехТуре>
<хз:зсйета>
Иллюстративная схема, зависящая от приложения:
<?версия хт1= 1.0 кодировка-'иТЕ-8'>
<хз:зсЬета хт1п5~’'Нпр://!п1еПгиз(.сот/к£огта1/1.0 хт1нз;хз=1игр://т™.Ау3.ог^2001/ХМЬ8сЬета χΜΐηδ^βηο^'ίηψί/Λνλν^.ν^.οΓΒ/ΖΟΟΙ/ΟΙ/χτηΙβηο#'' а»1Ьи1еГоппОе£аи11='‘шк|иа1 ШесГ>
<!— им порты —>
<хзятрог1 патезРасс=Ь11р://т1ег1Г1Ш.сот/Ос1ориз/1.0 зсЬстаЬоса1юп=Ос1ориз.хзс1'7> <!- элементы
1аг§е1Матезрасе=”Ь(1р://!п1ег1гиз1.еот/кГогта1/1.0 хп11пз:ос1=|1йр://1П(еПгиз(.сот/Ос4ори5/1.0 хт1пз:с1з=Ы1р://\¥и™.«3.ог8/2000/09/хт1аз1е# е1етеп1РогтОе£аи11=чиа11йе<1 <хз:е1етеп( пате=Тогре<1о (уре=Тогре4оТуре'7>
<х$:е1ешегй пате=Вгоа(1саз1Кеу 1уре=Вг<ж1самКеуТуре7>
- 117 012918 <хз:е1етеш пате=Вгоас1са5ГКеуМе1Ьоб 1уре=Вгоа<1саз(КеуМе1ИодТуре/> <!- типы —>
<хз:сотр1ехТуре пате=Тогре&>Туре”>
<х5:зециепее>
<хз:е1етеп: геГ- 'Вгоабсаз1Кеу’7‘>
</х5:5е<|иепсе>
</хз:сотр1схТуре>
<хз:сотр1ехТуре пате=ВгоабсазгКеуТуре>
<хз:зечиепсе>
<хз:е1етеп( геР=Вгоа<1саз1КеуМе1Ьо<1/> <хз:е1етепг ге!=осЕКеуОа1а'7>
</хз:зедиепсе>
<!- ίϋ является именем ΜΝΚ —>
<хз:аИпЬи(е пате='1б 1уре=хз:з1лпд’7>
<1— источник является именем МКТ ->
<хз:айлЬиГе пате=зоигсе 1уре=хз:зГг1пд/>
<7хз:сотр1ехТуре>
<хз:сотр1ехТуре пате=Вгоабсаз1КеуМейю<1Туре>
<хз:айпЬ1йе пате=А1£опЛт йхе<1='Ънр://таг11П-(1гт.сот/тапдго¥е/1.0/> <7хз :сот р!ехТуре>
</хз:зскста>
В.1. Дополнительные ограничения.
В.1.1. Узлы.
В одном варианте осуществления заданы следующие типы узлов.
Узел индивидуальности Ос1орик, которые являются корневыми узлами данного механизма ΌΗΜ (например, узел «устройство» или узел «программное обеспечение ПК»).
Другие типы узлов, например узлы «пользователь» или узлы для группы пользователей, например, узлы подписки или узлы принадлежности.
В одном варианте осуществления узлы содержат ключи (например, в Ех1епкюпк, например, 8сиЬаКеук), и должна быть возможность разделять открытую информацию узла (например, 1б, атрибуты и открытые ключи) и его личные расширения (которые, например, несут секретный и личный ключи). Кроме того, должно существовать по одной подписи на часть (открытую или личную), чтобы можно было экспортировать открытый узел со своей подписью, как есть (например, как параметр запроса к следующей лицензий).
В одном варианте осуществления, личные расширения переносятся в Ех1егпа1Ех1епкюп и подписываются. Открытый узел и его личные расширения могут быть упакованы в одном и том же элементе <Випб1е>, или могут приходить раздельно. Пример подписанного узла индивидуальности ОсЮрик приведен ниже в дополнении А к приложению В.
В.1.1.1. Атрибуты.
В одном варианте осуществления, каждая XΜ^-кодировка объекта «узел» несет <Айг1Ьи1еЫк1> со следующими полями <АйпЬи1е>:
Для индивидуальностей ОсЮрик:
<АЦпЬи1еЬ181 хт1п8='|Ы1р:/71п1.еПгиз(.сснп/Ос1ория/1,0>
<АйпЬи1е пате=ит:х-тагКплп1ег1ти51.сот:1уре>...<7А11г|Ьи1е> <АйпЬи1е пате=игп:х-таг1тлп(ег1ти51.сот:с1пк10''>...<АйпЬи1е> <АйпЬше пате=ит:хтаг1т. 1п(епги51.сот :тап и1ас1игег>.. .</ АйпЬи1е>
<АЙпЬи1е патс='Дт:х-таг11плп1ейгик1.сот:то<1еГ'>...</АйпЬи1е> <АйпЬи1е пате“=”ит:х-тагНплп1ег1гиз1.сот:уегз1оп>...</АипЬи1е> •УАйНЬшеГлзО
Для узлов других типов:
<А11пЬи1е1лМ хт1пз=Ь11р:/71п1ег1гиз1.сот/Ос1ориз/1,0> <А11пЬи1е пате—,ит:х-таг1тлп1ейги51.сот:1уре>...</АйпЬи1е> </АНпЬи1е1л5Р·
В.1.1.2 Расширения.
Согласно дополнению А к этому приложению В, в одном варианте осуществления узлы индивидуальности Ос1орик несут расширения для 8сиЬаКеук (ключи совместного пользования и конфиденциальности) и Тогребо (широковещательный секретный ключ). Узлы других типов несут только ключи совместного пользования 8сиЬа.
Все открытые ключи переносятся внутри элемента <Ыобе> в <Е.х1епкюп> в <Ех1епкюпЬ1к1>. Другие ключи переносятся в отдельном элементе <Ех1епкюп> вне элемента <Ыобе>.
В одном варианте осуществления, расширения <8сиЬаКеук> подписаны в <Ыобе>. В этом варианте осуществления, внутреннее <Ех1епкюп>, несущее <8сиЬаКеук> внутри <Ыобе> (открытые ключи) должно включать в себя элемент <бк:П1дек1Ме1коб>, а также элемент <бк:Ощек1Уа1ие>. Секретные ключи, переносимые во внешнем <Ех1епкюп>, должны быть подписаны, и это делается путем подписывания
- 118 012918 всего расширения. Аналогично, подписано расширение <То^реάо>.
В.1.2. Связи.
В одном варианте осуществления, элементы <ЫпкТо> и <ЬткРгот> элемента <Ыик> содержат только элемент <Ιά> и ни одного элемента <Э|дек1>. Элемент <Сои1го1> является необязательным. Дополнение С к этому приложению В содержит пример подписанного объекта «связь».
В.1.2.1. Атрибуты.
В одном варианте осуществления, связи не имеют обязательных атрибутов. Это означает, что <А!1пЬи1еЫк1> не обязателен и будет игнорироваться гибкой реализацией.
В.1.2.2. Расширения.
В иллюстративном варианте осуществления, показанном в этом приложении В, связи имеют внутренние расширения <8сиЬаКеук>, переносимые внутри <Ьшк>, и, таким образом, элемент <Ех!еикюг1Ык1> является обязательным. Кроме того, расширение <8сиЬаКеук> в связи не подписано, и, таким образом, ни элемент <άκ:^^деκΐΜеΐйоά>, ни элемент Щк:О|дек1Уа1ие> не переносится внутри элемента <Ех1еик1ои>. Это расширение <8сиЬаКеук> содержит зашифрованную версию открытого/секретного ключей совместного пользования 8сиЬа (в элементах <Рпуа1еКеу> и <8есге1Кеу>) конечного узла с открытым или секретным ключом совместного пользования 8сиЬа от начального узла. Это шифрование сигнализируется с использованием синтаксиса шифрования ΧΜΕ Согласно варианту осуществления, представленному в этом приложении В, атрибут ΎιΚΌάίΐ'^ элемента <КеуОа1а>, дочернего по отношению к элементам <Рпуа1еКеу> и <8есге1Кеу>, задан равным хт1еис. Дочерним элементом этого элемента <КеуЭа1а> будет элемент <xеис:Еис^урΐеά^аΐа>. Имя ключа шифрования объявлено в элементе «еуИчГог-ККеу^атеГ'.
В одном варианте осуществления, если ключ шифрования является открытым ключом, то элемент <КеуNате> является именем пары, которой принадлежит ключ;
если зашифрованные данные, например секретный ключ, слишком велики для шифрования непосредственно открытым ключом, генерируется промежуточный 128-битовый секретный ключ. Затем данные шифруются этим промежуточным ключом с использованием, например, аек-128-сЬс, и промежуточный ключ шифруется открытым ключом (с использованием элемента <Еис^урΐеάКеу>).
Фрагмент ΧΜΕ-кода будет выглядеть примерно так:
<1—Е(1, <1а(а) ->
<Епсгур1е(Юа1а хт1п5=|’Ьйр'.//ул¥¥1’Л¥3.о1'2/2001/04/хт1епс#>
<ЕпсгурйопМе(Ьос1 Α1§οίίΐΚηι=’ΊΐΠρ://ν.ΓνΛν.ν.Γ3 ,ог§/2001/04/хт1епс#аез128-сЬс/>
<Кеу1пСо хт1пз=Ь«р:/7улу\у.у/3.ог8/2000/09/хт14з12^>
<!— Е(РЦВа, I) ->
<Епсгурге<1Кеу хт1п8= Нир :/ΑννΛν. ν/З .ог§/2001 /04/хт 1епс# >
<Епсгур«опМе1Ьос1 А1§оп1Ьт=Ь«р://ул>™.«'3.ог§/20<И/04/хт1епс#г8а-1_5/> <Кеу1пСо χπι1η5=Η«ρ;//νννπν.νν3.θΓ8/2000/09/χηιΙά5ί§#> <КеуКате>ит:х-осЮри5.1п1ет(п181.сот:кеу-ра1г:300а</КеуМате> <7Кеу1пй» <С1рйегОа1а>
<С1рВегУа1ие> ДгеСО4КАРЕтЕ52(1^бСкЬКе§рМ5куН0Оу/о/иО978Ра811(¥иМоо2еО4а0Ь785¥пВ 13ра12иЕУчК9У5ТСиаОсН7\¥ХХ¥ВЕ15д1п¥КкУО£\\7кГпКг98иОРуи90Р]^аЕР/ЗА ВЬЯиАитух¥Х47чОУ0(]В(5О6чгЕ85ВОКтик+з98<1кРК8= </С1рЬегУа1ие> </СлрЪегОа{а> </Епсгур1едКеу>
<УКеу1пГо>
<С|рЬегОа1а> <С|рЬегУа1ие> с8кВ]4ВкгСОУх/аТЗУ4«2ХстеТУЬг8{ННЛ1СОО)и1л¥о11УОУ¥2ККСр1_УУ+пиСХС/5 19Ти+81М1аМ11<ЭиркС2<2118аТ1>1с111С8хОуВоА6Х11/ЬтугЕО37в+а1/81ТтЙЧрЗ<Эс1Ь νΤ3ΐ7χ9ϋ01ΜρΙηινΡΈ]ρΑυ]ΤΤνΓυΝ32§4Βχ5Ρ7ΤΌ8€ΙΒλ¥ΝΑ€4Ιι896ηΡΠ§τηιζο05ρΒ д4а6т^ГКО5В0кУ7тУЬкасЫо™ХкАк1^с/О11ХА+9ЬНс11Л11хеа]оХТЧРГАаВ29РМЗЬ ри1хЬхОАааАЛ)хоКе1Т181 п6аНкяа1к¥ЬСрКк1гНВо\¥НууТуОЬЕ1Е)НУЕРеС36х8Н ВЬгрТ298ШКикХ£аУб¥УдсеМдУХиВУЬЗс2Рик1НПхеаВу1се8х10К2ро6Р}их1Ь Ьп5КиМг/Рх\¥р7гка5578б8740с\таНбЗ+7Вй1е11хРК 1 СпУОЗЫШ7Ы1/а§уО91уиО Кусел8ЕУ9КА5Еху/б215/ёои1|ри8г7056ХсЕ4/1Во4Т\УОк1уК/у8я50А/0УаО9 УЗоЕК 1 ρ3ρΥπΗννπ/ΙεΧΜ485ΒΟ31 с^7пу£К71КУк2р\уК9Р6р8у57а+К4Ь2КЕ>т£иН ζθ/£282ХсоРЬ9обт V АЕЕе]7+аЬ ν/ято Неу ккК+ОркРпгуя νΧ УКРкрЬЬсУ άζ] ζΙ МУ 8ϋρΧΒΧ™χ7\ν6ρυΚΧΗίβνν7Κ4ΚϋιΟ>3ννίν+ΖΡ1ρΙ9Ν5ΑΕΙν4ν\νγ4ΓΒοΒζΖ7€ΤΝΜΐίΚ ζηΗνΐΐ+3ν\νη5Ο0ΙΒχζυ9ν/ΙΡζΡ(Ι,-Κη2Η9Ε4ΤΙ71 ЬСа4УКЗиМрГ+ХМ81р9ЦЬРКСпМЬ 28КгМаА(1асеуорУу|1Р5р81дЙ1{}//а/ЬК4Е7}АкОя9е«к19гуяЯ6СРеК15оОМ]11 к^МхЗВКчНхтЗ 1Н1е32К(А==<'С1р11егУа1ие> </С1р11егОа1а> </Епсгур{еДРа(а>
- 119 012918
В.1.3. Объекты «лицензия».
В дополнении С к этому приложению В приведен пример подписанной лицензии (до того, как произойдет первая отмена, см. ниже раздел Соп!еп!Кеу).
В.1.3.1. Рго1ес1ог.
В иллюстративном варианте осуществления, показанном в этом приложении В, элемент <Соп1еп1КеуКеГегепсе> и элементы <Соп1еп1КеГегепсе> (например, внутри элемента <Рго1ес1ебТагде1к>) содержат только е1етеп! <1б> и ни одного элемента <Ощек1> В этом иллюстративном варианте осуществления, объекты Рго1ес1ог не содержат обязательных атрибутов или расширений; элементы <ЛйпЬи1еЬ1к1> и <Ех1епк1опЕ1к1> являются необязательными и будут игнорироваться.
В.1.3.2. Соп!еп!Кеу.
В иллюстративном варианте осуществления, показанном в этом приложении В, объекты Соп!еп!Кеу не содержат обязательных атрибутов или расширений. Поэтому, элементы <Айг1Ьи1еЬ1к1> и <Ех!епк1опЕ1к1> являются необязательными и будут игнорироваться.
В одном варианте осуществления, элементы <Соп!еп!Кеу> содержат элемент <8есге1Кеу>, который представляет фактический ключ, который будет использоваться для дешифрования контента. <КеуОа1а>, связанный с <8есге1Кеу>, зашифрован. В одном варианте осуществления, обязательно, чтобы атрибут епсобшд элемента <КеуЭа1а> был задан равным хт1епс.
В одном варианте осуществления, существует два разных варианта для объектов Соп!еп!Кеу: (1) До первой отмены устройства или приложения ПК: в этом случае, ключ контента Кс, представленный элементом <8есге1Кеу>, шифруется только ключом 8сиЬа (открытым или секретным) сущности, к которой привязан контент (например, пользователя). (2) После первой отмены, когда ключ контента шифруется согласно схеме широковещательного шифрования Μαΐ'ΐ§ΐΌ\Ό. Затем результирующие данные шифруются ключом 8сиЬа (открытым или секретным) сущности, к которой привязан контент. В этом случае, мы имеем супер-шифрование.
Иллюстративные методы шифрования элемента <Епсгур1ебОа1а> в случае супер-шифрования описаны здесь в другом месте. Ниже объясняется, как применить это к случаю Ь.
В одном варианте осуществления, синтаксис хт1епс для шифрования ключа контента Кс согласно схеме широковещательного шифрования Μαΐ'ΐ§ΐΌ\Ό таков:
<Епсгур£есЮа1а хт1п$-Ъйр:/Лтату.^3 .ог^/2001 /04/хт1епс#> <ЕпсгурНопМеЙ1ос1 А1бог»Йип=зее (*)/>
<Кеу1пй> хт1п8=Ъ£ф:/7ил¥лл¥3.ог£/2000/09/хт1<1з1§#’'>
<КеуИате>$ее (**)<КеуКате> <Кеу1пй>> <С|рЬегОа£а>
<С1рНегУа1«е>зее (***)<7С1рЬегУа1ие> </С1рЬегОа(а> </Епсгур£еШЗага>
(*) это ИКЬ, идентифицирующий схему широковещательного шифрования Μπ^ιό^ό, которая, в одном варианте осуществления, также является алгоритмом <В^оабсакίКеуΜеΐйоб> расширения <Тогребо> в вызове схемы хт1, зависящей от приложения кГогтаЕхкб.
(**) это имя дерева ключей Μαΐ'ΐ§ΐΌ\Ό. В одном варианте осуществления, это значение должно быть таким же, как у атрибута «коигсе» элемента <Вгоабсак!Кеу>, заданного в кГотий.хкб.
(***) это значение, в кодировке Ьаке64, последовательности Α8Ν. 1, представляющей шифрование ключа контента Кс согласно алгоритму широковещательных ключей Μαΐ'ΐ§ΐΌ\Ό:
ЗЕОиЕЫСЕ {
ЕадБ ΒΙΤ 5ΤΚΙΝΟ кеуз ОСТЕТ 3ΤΚΙΝ6 Д______________
В одном варианте осуществления последовательность байтов <Епсгур1ебЭа1а> согласно вышесказанному, шифруется ключом совместного пользования ксиЬа (открытым или секретным) сущности, к которой привязана лицензия. Если используется открытый ключ, то применяются те же соглашения, которые описаны ниже (см., например, шифрование открытым ключом), и необходим промежуточный ключ, если последовательность байтов <Епсгур1ебОа1а> слишком велика для открытого ключа К8А 1024. Пример ΧΜΕ-кодирования такого объекта Соп!еп!Кеу можно найти в дополнении Ό к этому приложению В.
В. 1.3.3. Соп!го11ег.
В одном варианте осуществления объекты «контроллер» не содержат обязательных атрибутов или расширений. Поэтому элементы <АйпЬи1еЕ1к1> и <Ех1епк1опЕ1к1> являются необязательными и будут игнорироваться гибкой реализацией.
В одном варианте осуществления значение атрибута А1доп11ип элементов <^^декίΜеίйоб> всегда равны 1Шр://\\л\лу.\у3.огд/2000/09/х1п1бкщ#к11аЕ
В одном варианте осуществления <Соп!го1КеГегепсе> должен иметь элемент <Ощек1>. Элемент
- 120 012918 <О|дек1Уа1ие> должен содержать кодировку Ьаке64 дайджеста объекта управления, на который имеется ссылка.
В одном варианте осуществления, если подпись на контроллере является подписью РК4 (гка-кйа1), элементы <Соп!еп!КеуКеГепсе> (в элементах <Соп!го11е6Тагде!к>) должны включать в себя элемент <Όίдек!> и элемент <П1дек!Уа1ие> должен содержать дайджест незашифрованного ключа контента, внедренного в объект Соп!еп!Кеу.
В.1.3.4. СосИгок
В одном варианте осуществления, объекты управления не содержат обязательных атрибутов или расширений. Поэтому элементы <АЦпЬи1еЫк1> и <Ех1епкюпЫк1> являются необязательными и будут игнорироваться гибкой реализацией.
В одном варианте осуществления, атрибут «1уре» элемента <Соп!го1Ргодгаш> задан равным р1апк!оп, и атрибут Ьу!е-со6еТуре элемента <Со6еМо6и1е> задан равным Р1апк!оп-1-0.
Приложение В
Дополнение А. Пример подписанного узла индивидуальности Ос!орик <Вшк11е хт1п5:б8=Ьпр://тулу.\¥3,огй/2000/09/хт1б5к# юп1п5;хепс=11Кр://'у^л.\у3.ог&/2001/04/хп1кпс# хт1п8=Ьйр://тСе1й-и81.сот/ОсСопи$/1.0 хт1п5:ха|=Ьпр;/ЛулуулЮ.огд/2001/ХМЬ5с11ета-экземпляр
Χ5Ϊ: зсЬетаЬоса! ΐ оп=11Цр://тСег1 гив1. сот/кГогтаС 1,0
С:ЮОСиМЕ~ 1 \)и1|еп\Ое5к1ор\кГоппа!\кп)гта(.хз6>
<!— сначала узел с открытой информацией—>
<БЫе 16=ит гкГогтак άεν Ϊ се:0001 >
<АйпЬи1е1л5О <Айп ЬиСе пате=”ит :х-таг! ΐ η. ί пСегСгивС. сот :1γρε>άβνΐ се</АйпЬиСе>
< Айп Ьи!е пат е= ит: х- т аг! ί η. ί пСегСгизС .сот :6пк_ ϊ й>ит гкГогтаС: т апдгоуе :0001</ Айн Ьи1е>
<Αήτϊ Ьше пате= ит: х-т аг1 ϊ η. ί п!егСги$1. сот ;т ап ийсШгегДй > 8ΟΝΥ </АйпЬи1е>
<АйпЬи1е пате=игп:х-таг1т.т(е|4ги81.сот:тойеГ>ит;зопу:ууа1ктап</Айп1>1йе>
< Айп Ьи(е пате-’ ит: х-т аг! ί η. ί пСегСгизС. сот: уегз юп>ит: волу: \уа!кт ап:002а</ АШ1Ьи1е> </ЛйпЬиСе1лзС>
<Ех1еп51опЬ1з1>
<Ех1епзюп 1<1=ит:кТогта1:4еу1се:0001:8сиЬа:риЫ1с>
<8сиЬаКеуз>
<РиЫ ссКеу М-'ит :ккогта1:6е уке:0001: зсиЬа: р иЫ ΐ с: зЬаппд ра11=ит;кГогта1:4еу1се:0001:8сиЬа:ра1г:8Йапп£> «КеуОаСа епсо41пе=”Ьазе64 1огта1=Х509'>МПС.. ,МЕЬВ</КеуОа(а> <РиЬйсКеу>
<РиЫ 1сКеу ί6-' ит :к!огта1:6еν ке:0001: всиЬа: р иЫ ί с :согйМепПа1 ί Су ива^е- сопйбепб аШу ра11=ит;кГоппаЫеу1се:0001 :эсиЬа:ра1г:сопй(1епйа1йун>
<КеуОаСа епсо<Йпе=Ьа8е64 ГогтаС=Х.509'>МИСкОСС... уМВМ52</КеуОаСа>
</РиЫ1сКеу>
</5сиЬаКеув>
<ΟΪ£δ8θ <Ωί девСМеОюЙ хт 1пв=11йр://илт.м/З ,ог§/2000/09/хт 1<1в ΐ
- 121 012918
А1доп(Ьт=11йр://чт™.У¥3.ог§/2000/09/хт1<151§#5ЬаГ,/>
<Г1§е5ГУа1ие хт!лз=11йр ://\νν™ ,\ν3 .огд/2000/09/хт1бз12#”> 00Ζ6ΒΥ 8ОррХз</0 ί дезТУ а1ие> </0Ϊ£β3Ϊ>
</Ех1епзюп>
</Ех1спз1опЬ130 </Νο6β>
<!— затем личное расширение ЗсиЬа —>
<Ех1епзΐοη И= ит:кГогтаГ:беуке:ООО 1 :зсиЬа:рпуаГс” зиЬ)ес(=ит:кГогтаПбеуке: ООО 1> <5сиЬаКеуз>
<Рпуа£еКеу |б-игп;кйпла1:4еу|Се:0001 :зсиЬа;рпуа1е:зНап倫 ра1 г= иго: кГогтаГ: беуюе: ООО 1 :зсиЬа : рая: зкап пд''>
<КеуОа1а епсобт8=Ьазеб4 ГогтаГ=РКС58>МПСб£1ВАОА1Ч... ОХуу/ОЬд==</КеуОаТа> </Рг1Уа1еКеу>
<Рп уа1еКеу ί б= игл; кГогта! :беу!се :0001: зси Ьа:рп уа1е χοηίϊ бепйа! бу изаде-’соп Пбепб а I ϊ Ту ра1г='' ит: к/огтаг :б еуке : ООО 1 :зсиЬа: рак; солйбе лба! ку >
<Кеу£>а1а епсоб|П8=Ьазе64 £огта1=РКС£8’'>МПСб\у1ВАОА1Ч... с[4о1о§34=</КеуОа(а1> </Рпуа(еКеу>
<8есге(Кеу |4=пит:к£оппа1:беу1се:0001 :зсиЬа:зесге(:511апп§>
<КеуБа(а епсобп1£=Ьа5е64 ГогтаТ=,'КА1У>21п2/2сЬ21оО/12о9хТп1уА=</КеуОа1а> </8есге(Кеу>
<8есге1Кеу 1б=ит:Иогта1;беУ1се:0001:5сиЬа:зссгсГ:сопй4спПа1|(у иза§е= солйбе лбаНТу >
<КеуОа1а елсобтё^Ьазебб·' {огта(-КА5¥>0С38ЬсОКХУбСЬХ4О2Т7ХКуд=</КеуОаТа> </8есге(Кеу>
</8сиЬаКеуз>
</Ех1епз1ол>
<!— затем личное расширение Тогребо —>
<Ех1епзюп 1б=ит:к£огтаг:беу1се:0001:1огребо 5иЬ]есг=ит:к£огта(:4еУ1се:0001 >
<Тогребо хт1пз=(11(р://|л1ег1гиз1.сот/кГогта1/1,0>
<Вгоабсаз1Кеу 1б=ит:кГоппа1:тап2гоуе:0001 >
<Вгоабсаз(КеуМе1Ьоб А1доп1Ьт=”Ьир://таг11п-бгт,сот/тап£ГОУе/1.0'7> <КеуОа1а хл11п5='Ънр:/бп(ег1п1з1.со1п/Ос1ори5/1.0 епсобт§=Ьазе64
Гогта(= ΚΑ\ν >.. „</КеуОа1а>
</Втоабсаз1Кеу>
</Тогребо>
</ЕхТепзюл>
<!-- затем подпись на открытой части —>
<81£па(иге ΜηΙη5=Κΐίρ://\ν\ννν.Λν3.θΓ^2000/09/χπιΙ63ί§^''>
<Й1£псб1пй» <СапопюаНга{ юпМеНюб А1 §о птйт=Ийр -.И улучу луЗ . огд/2001/10/хт1-ехс-с 14п#7> <81дпа1игеМеЙюб А]£оп1кт=ййр://ул¥1Л'.уг3.оге/2000/09/хт1451£#гза-5Ьа17> <Ке£егепсе иК1=ит:к£огтаПбеу|се:000Г'>
<ГгапзГогтз>
УГгапйогт ΑΙ§οπ(Ιιιη= Ьйр: //чууау. ос!ориз-бгт. сот/2004/07/£огта(- ϊ лб ерепбеп(-сапо </Тгапз1бгтз>
ОфезТМебюб А12ог1111т=кйр://чучучу,чу3.огд/2000/09/хт1йз1ё#з11а1 7> <П|£сзГУа1ие>§15ро07МиА£)сркР|с|21ю8НЬЕр=</Е>1£сзГУа1ие>
</К.еГегелсе>
</8ί§.ηβ4Ιηίο> <8|£р1а1игеУа111е>£15ро07МиА£)сркР|С1г11о8НЪЕР=</81дпаи1геУа1ие> <Кеу1л£о>
<Х509Па1а>
<!- поместить сертификат открытого ключа для ключа подписи здесь <Х509СегйГ1са1е>...</Х509Сег11йса1е>
<1— и цепь сертификатов без корня, если необходимо —>
<Х509Сег(1Г1са1е>.. . </Х 509Сегп КсаТе>
<Х509Оа1а>
</Кеу1лГо>
<81§ла1иге>
<!— затем подпись на личной части —>
<51дпа1иге хт1п5=’’ЬИр://уге(-у/.чуЗ .огд/2000/09/хл11б518#>
<8|§ле41лй»
- 122 012918 <СапошсайгайопМе1Ьо(1 А1£ог1Лт=Ь«р://\т\¥.ад3.ог8/2001/10/хт1-ехс-с14п#/>
<81£Па1игеМег1кх1 А1цоп Й1т= Ьйр луЗ .ог^/2000/09/хт1<1з ΐ §#гза-ь На 1/>
<Пе£егепсе ЦК1-'иго: кГогта» :0001 :зси Ьа: рп уа(е>
<ТгапзГогтз>
<Тгап$Гогт А1§ог1Й1т=,Ъйр://нгцп^.ос1ориз-дгт.сот/2004/07/Гоппа{-1пдерепдепЬсапо#> <ГГгапзГогтз>
<О)йе51Ме0юс1 А1§огй1мп=’,ЬПр;//мп™.м’3 .оге/2000/09/хп)Мз1§#з11а1 /> <О1§е8(Уа1ие>£15 φοϋ7Μυ А^ сркР ίείΖΚο8Η6ΕΟ=</Οί^5ϊν а1 ие>
</КеГегепсе>
«еГегепсе иВ.Г=ит:кГогта(:4еУ1се:0001:1огредо>
<ТгапзГогтз>
<ТгапзГогт А1цоп(Ьт=,Ъйр://уутлпА,-осГориз-д11п.соп¥2004/07/(0г1па1-1пдерепдеп1-саио#'’/> </Тгапз&гтз>
<дз:О1§ез1МеЙюс1 А18Ог1(Ът=1аЙр://и¥™.№3.ог§/2000/09/хт1дз1§#з11аГ,/> <4з:О1§е8(\''а1ие>97тО£п'л0\'Е/ЕС9Нс¥Ок<М5:О1ёе51Уа1ие>
<КеГегепсе>
<Α>ί§ηβ<ΙΙηίο> <81^ахигеУа1ие>£150оС7АГОАщсркР1С121ю8НЬЕС>=</51£па(<1гсУа111е>
<Кеу1пСо>
<Х509Оа1а>
<!— поместить сертификат открытого ключа для ключа подписи здесь —> <Х509Сегййсаке>.. </х509СегйГ1Са1е>
<!— и цепь сертификатов без корня, если необходимо —> <Х509Сегййса1е>,..</Х509Сегййса1е>
<Х509Ца1а>
</Кеу1пГо>
</81§ла1иге>
</Вш1<11е>
Приложение В. Дополнение В. Пример подписанной связи Оскорик <?версия хт1-Ί.0 кодировка=иТР-8?>
<!—Образец файла ХМЬ, сгенерированного ΧΜί8ΡΥ ν2004 ге1. 2 ϋ (Ьйр://мп™.хт1зру.сот)—>
<Вип<11е хт1пз=Ьпр://|п1ег1гиз1.сопъ'Ос1ор115/1.0 χηι1η5:^3=ΗίΤρ://Μτννν.νν3.θΓβ/2000/09/χιη145Ϊ§# хт1пз:хепс-Ъйр://т™.уу3.ог£/2001/04/хп11епс# хт1пз:хз1=11Пр;//игт¥.м'3.о^/2001/ХМЕ5сЬетаэкземпляр хз1:зс11етаЕоса(юп=’ЪНр://|п(ег1гиз1.сот/ОсГориз/1.0
С:\¥*з\Ос1ориз\8оигсе\Хт1\8сЬеп1аз\Ос1ориз.хзд>
<Ыпк М-'ит:кГогтас1шк:<1еу1се:0001 :ю:изег:1234>
<Ехкеп8ЮпЕ15С>
<Ехкепзюп |д=ип1:кГоппа1:11пк:де¥гсе;0001:1о:и5ег:1234;зсиЬа>
<8сиЬаКеуз>
<!-- Е(РиВс1еу’кс, РШУизег) -->
<РпУа(сКсу и=игп:кГогта1:изег:1234:зсиЬа:рг1уа1е:зЬапп§ ра1г=ига:кГогта1:и8ег.1234:зсиЪа:ра1г.зкагт£''>
<Кеу6а(а епсосйп£=хт1епс &гта(=РКС88>
<!-- Е(1, РКА'изег) I: промежуточный ключ--> <Εηοι>ρΙβάΟβΐ8Χΐη1η5=Ηίίρ://Μπνιν.νν3.οΓ§/2001/04/χιη1βηο#>
<Епсгур11опМеГЬо0 А15огй11т=|’ййр://\¥Ч,ч'.мгЗ,ог§/2001/04/хт1епс#аез128-сЬс|7> <Кеу1пГо χηι1η5='ΊιΙίρ7/ν.’\ν\ν.ν/3.θΓ£,’20ϋ0/09/χιη1ά3Ϊ2#>
<!-- Ε(ΡυΒάβνίςβ, I) -->
<Епсгурке4Кеу хт1пз=11йр://м™™.чгЗ.О1,§/2001/04/хт1епс#>
<ЕпсгуρΙίοηΜεΙΗο4 ΑΙ^οπ [1ΐΓη=’ΊιΗρ://νηννν.\ν3 .ог^'2001 /04/хт1епс#гза-1 _5’7>
<КеуГпГо хт1п5~11(тр://г¥Ул¥.у»3.ог^2000/09/хт1дз1#> <КеуМате>ит:кй>гта1:4еУ1ее:0001 :зсиЬа:ра1г:зЬапп§</КеуКате>
</Кеу1п(б>
<Слр11егОа(а>
<С1р11ег''/а1не>£РеСО4К... з98дкРК8=</С1р11ег¥а1ие>
</С1рЬегОа<а>
</Епегур(едКсу>
</Кеу1пГо>
<С1р11егОага>
- 123 012918 <С|рЬегУа1ие>
с8ЬВ)4ВЕгООУу...Н1еЗгК1А==</С1р11егУа1ие>
</С|рЬегБа(а>
</Епсгур!е<ПЭа1а>
<7КсуОа1а>
</Рпуа1еКеу>
ΕίΡΙΓΒάενκβ, Зизег) ->
<8 ес ге(Кеу ΐ б-’ игл: к4огта1: и зег: 1234:5есге(: аЬап пд>
<КеуОаЗа епсобт§=хт1епс Гогта1=ЕАА'|>
<Епсгур(ебОа1ахт1п5=11ар://луту.х¥3.ог2/2001/04/хт1епс#>
<ЕпсгурбопМе(11об Α12οη(Ιιπι=1ί(ρ://ν™χν.\ν3,οΓ§/2001/04/хт1епс#г5а-1_5/>
<Кеу!п£о хт1п8=Ьйр://угту.ууЗ ,о^2000/09/хт1<151£#'’>
<КеуМате>ит:Иот1аЫеУ1се:0001:5сиЬа:ра1г:5Напп§</КеуБате>
<Кеу1пГо>
<С|рЬегВа»а>
<С1рЬегУа1ие>0НУаН... ЦЕА=<С|рНегУа1ие>
</С1рНегПа1а>
</Епсгур1е40а(а>
</КеуОа1а>
</Зесге(Кеу>
</8сиЬаКеуз>
</Ех1епзюп>
</Ех1еп5юпШ1>
<Е1пкГгот>
<1б>ит: кГогтаС безлес :0001 </ϊ б>
</Е|пкРгот>
<Б1пкТо>
<1б>ит:кй>гта1:и5ег: 1234<Лб>
<ДлпкТо>
</Б1пк>
<8 1§паГиге хт 1пз= Ь«р г/УччузулуЗ. огв/2000/09/хт1бз1 §# >
<8ΐβηε6Ιηίο>
<Сапотса11габопМе1Ьоб А12огМп1=',ЬПр:/Лу\уху.\у3.ог#2001/10/хп11-ехс-с14п#'’/>
<5ί§па1игеМе(1ю4 А 1&огк1ил=Ьйр-.//ντνννι.νβ,ог%/2000/09/хтМзί£#гза-зка 1 />
«еГегепсе (Ж1-’ит :кГогта1: I ί л к: бе νί се: ООО 1: ю :изег: 1234>
<ГгапзГогтз>
<Тгапз ίοπη А1£оп(11т= КПр ://ν/ν/νζ. ос(ориз-бгт, сот/2004/07/ίθΓΠΐ а(-ш б ерепбелЕсало#/> </Тгапз(огтз>
<01£ез1МеЙюб А1д>гкЬт=КПр:/Луу™.\у3.ог§/2000/09/хп11б81£#511аГ7>
<0щез1У а! ие>§15(?о07Ми А дсркР »с ί Ζ1ιο8Η1ΕΟ=</ϋί§68ΐν а1 ие>
<Ке(егепсе>
</81§пеб1п(о>
<5 !§пашге V а1ие>§15роП7Ми Ад сркР к ίΖΗο 8НЪЕ0=</8 щпа I иге Уа I ие>
<Кеу1л(о>
<Х509Ба1а>
<!— поместить сертификат открытого ключа для ключа подписи здесь <Х509Сег11йса1е>.. ,</Х509Сегйй са1е>
<!— и цепь сертификатов без корня, если необходимо ->
<Х 5О9СегййсаГе>.. .<1X509СегПй са(е>
</Х509Оа1а>
</Кеу1п£о>
</8|§паШге>
</Випб1е>
- 124 012918
Приложение В. Дополнение С. Пример подписанной лицензии Оскориз (без отмены) <Вип<11е хт1п8=Ь«р://т1е11гиз(.со1п/Ос1ориз/1.0'' хп11пз:х.51=''Кйр7Чтлху,тл<Гог&'2001/ХМЬ8сКегпа1П5йпсе х81,8сЬетаЬосаГюп-'Ьйр://|П1ег4ги5(.сот/Ос(ори8/1,0 СА«8\Ос1ориз\8оигсе\Хт1\8сЬета5\Ос1ори8.х5сГ>
<Со1Йеп<Кеу 14-игп:х-ас1ориз.т1сг1ги81.сот:контент-кеу:2002> _ <КеуОа1а епсо<йп2=,'хп11епс'’ £огта1=КАкУ>
<Епсгур1еШЭакахт1пз=|'Кйр://,\уту.ч'3.ог§/2001/04/хт1епс#>
<Епсгур1юпМе4йой А18оп111П1=11йр:/Луут'.1у3.ог§/2001/04/хт1епс#ае8128-сЬс'7> <Кеу1п£о хт1п5=‘Ъ11р://т¥и.ч'3.огв/2000/09/хт1<1818#,'> <КеуЯате>ит:х-ос[ори84п1ег1ги8и<лп:8есгег-кеу:303с</КеуКап1е>
</Кеу1п£о>
<С1р11еЮа1а>
<С!рйегУа1ие> МСК0ЬОаоуиО2о6г5№1гОО5МЙ1игС1У20о94/ОЙЭ5аНЪиЗд2у2г8^КЫерЕуКа <С1рЪегУа1ие>
</С!рЬегГ)а1а>
</ЕпсгургесЮа1а>
</КеуОа1а>
</8есге1Кеу>
</Соп1епЖеу>
<Со1йеп1Кеу |4=’'ит:х-ос1ор1Клп(е(1т1.соп1:ковтент-кеу:2001 ’>
<8есге(Кеу И=игп:х-ос1ори8лп1ег1ги81.сот:зесге1-кеу:2001 >
<КеуОаха епсо4т§=хи11епс Гогта1=|’КА77>
<Епсгур1е<Юака хт1пз='Ъйр :/Αν\ν\ν. ν/З .ог^/200 I /04/хт1 епс#>
«ЕпсгургюпМеЙюй А1§оп1Ьт=Ьйр ://\уту.зуЗ .огр/2001 /04/хт1епс#Г8а-1_5 У? <Кеу1п£о χηι1η3=ίι«ρ://3ν«τν.\ν3.θΓ§/2000/09/χιη)ά8Ϊ§#>
<КеуНате>ит:х-ос1ориз.т1ег£ги5(.сот:кеу’ра1г:300с</КеуЫате>
<Кеу1п£о>
<С1ркегОа1а>
<С|рЬегУа1ие>
Ш51 сП 1 ВззууЛ2СйРоР]Му1РпЗоое17ук2РА5п1К¥06К82К2]хР[ЖСтЬО1 ΥΖ5Ην 610ч$ЗИу74/трГЗАЩЮ<а9/утта8УВхипу426В9ПкгТТ4СОчМ)а+?,гРОКЪ9КгС дпК1У£и1тк8<1О+}ах\7518ρ8ίρ4ΜΟρΟΖΒ63ζίνουΒ07ςΕ= </С1р11егУа1ое>
<7С|рЬегЦа1а>
</ЕпсгурТе<11>а1а>
</КсуОа(а>
</5есге1Кеу>
<7Соп*етКеу>
<Соп1го11й=ит:х-ос1ори£лпГсПп151.сот:соп1го1:000Г,>
<Соп1то1Рго§гат 1уре--Р1апкют>
<Сос!еМоск11е 6айт-кодТуре=Р1апк1оп-1 -0>
АААВипВг<?00АААА2сСГГ\7ААААА1ОК2хуУ|пЕзЬк9иТ69Ь2АААААААЕкЕ1с1Сг|уЬ|59Ь6Р5ЬкМо7 ЧтгАААААР§АААСтсСФивдЕААААЕО8ЕАААААВ9ЕААААС1АМВААААВВоВААААН2иЬА0 ΑΑΑΌ«ΎΑ0ΑΑΑΑ0βΑρΑΑΑΟΙΕΑ0ΑΑΑΑΙ§Α«ΕΑΑΑΑΕθ5ΕΑΑΑΑ7ΒΚ3ΒΑΑΑΑΒΙΐ6ΒΑΑΑΑΑΒυ В/////хЦВААААВВоВААААР\уиВААААВВоВААААНеиа1АЕААААвОАЕААААЕОёЕАААА7ВКо5 А9ЕОХЗоЕА9ААААУУАОАААААУА&///8УААААЬпВгВГМРУЗВуеНУйЫсхрЬтиЬк1гТт9кгУЛ¥ Х¥Ко¥У/35гОААААААи31г4СУ1ЕкЬусЗ<ЗиК2У0У6112УН0¥\71«ААААААВ1ст46еС1у¥ЗКусНУ2П т1исЮУуаНЛсЗ<2и¥29Ют5у2ОибМОА\уМиА= </Со4еМос1и!е>
</Соп1го I Рго ггат>
</Соп<го1> <Рго1ес1ог>
<СопкешКеуКе(егепсе>
<й> игп :х-ос1орш. 1гйеПги8Г.сот :конте нт-кеу:2002</И>
</Соп4еп1КеуВ.е£егелсе>
<Рго(ес1ес1Таг§е15>
<Соп1епЖе Гегепсе>
<М>ит:х-осЮриз Лп1егт1зг.соп):контент:2001 <Л<1>
</Соп1еп(К.е£егеп«>
<Соп1еп1Ке £егепсе>
<1<1>ит:х-ос(оризлп1ег1ги51.сот:контент:2002</1<1>
</Соп 1сп1Кс Геге псе>
</Рго1ес(ес1Таг8е18>
<'РготесЮг>
<Рго1ес1ог>
<Соп{епгКеуКеГегеисе>
<й>игп :х-ос1ори5 .ййеПгиЯ .сот: контент-кеу :2001 <4 4>
- 125 012918 </Соп1еп1КеуКе1егепсе>
<Рго(ес(е<1Т аг§е1з>
<Соп!еп!Ке£егепсе>
<1<1>ит: х-осГориз. ΐ МегСгиМ. сот :контенг:2003<71с1>
</Со п(еп1Ке Гегепсе» <СопГеп1Ке Гегепсе>
<1д>ит :х-ос1ориз. ΐηΐεΓί гиэ1. сот :контент:20040 ό>
</Соп1еп(Ке(егепсе>
</РгоГес1ес1Таг£е(5>
<7Рго1ес1ог>
<Соп1го11ег |4=ит:х-осЮри£. 1п1егЕги5Г.сот:соп(то11ег:0001 >
<Соп1го1Ке(ёгепсе>
ит :х-ос1ор из, т(ег1гизг.со т: соп1го!; ООО 1 <7Ιά>
<О1£ез1>
<ϋί§βΐ(Μβ Ιίιοά А1 гоп1Ьт-Ьйо :/Лу(у\улуЗ .оге/2000/09/хтШз 1 хт!пз=“ р://улусу луЗ .огд/2000/09/хт 1(Ы />
<Э1§е5(Уа1ие хт!п8=,'Ь«р://«АУ«.У¥3.ог8/2000/09/хтШ8#’,>02АСК5674287НР45СТА5 Α66ϋ70125РГ5601 А63Г7</Ы§ ез1Уа!ие>
</01ее51>
</Соп!го !К.е1егепсе>
<СопГго 11едТаг£ей>
<Соп!еп1К еу КеГегеп се>
<14>ит ;х-ос(ориз. ΐ п(сгТгизГ.сот : контс нт-к еу:2002</1б>
</Соп1еп(КеуКе1егепсе>
<Со п1еп1Кеу КсГегепсе>
<1 с1>игп:х-ос1ориз. ί пкпгизг. сот :контент-кеу:2001</Ш>
</Соп1егйКеуВ.е1егепсе>
</Соп1го11е<1Таг£е1з>
<Соп1тоПег>
<5 ί§ па(иге хш| пз= Ιι Пр'.//νηννί,ν/3. οί^/2000/09/хтИз ί <8ΐ§ηβ6Ιη£ο>
сСапотсаИхабопМеОюО А18ОП1Ьт=1«Гр://ч,УЛУ.су3.ог£,,2001/10/хт1-ехс-с14п#/>
<81£па1игеМе111О<1 А12ОП1Ьт~Ъйр://уиуху.су3.ог§/2000/09/хт1<1з)§#11тас-зЬаГ'/>
<Й.е1ёгепсе им=игп:х-ос1ориз.т1ег1п181.сотхоп1го1кг:000 Г>
<Ггапз1оп115>
<Тгапз/опп А1§огй11т= ΊιΠρ://суслу. ос!ориз - бгт, сот/2004/07/ίο гт аьтб ерепбепЬсапо#/>
</Тгап81огтз>
<ΡΪ8β3ίΜβί1ιοά А1§оп<1т1='Ънр://слусу.су3.огд/2000/09/Х1П1(151§#з1)аГ/> <01ее5»Уа1иОА42СгРК400уЬ/М0и'д0ЕгКпу181 У=</ЕН§ез1Уа1ие> </КеГегепсё>
</8ί§η«ΙΙηίδ>
<81£паП1ге Уа1 ие>§15 фоО7МиАд) сркР ίσίΖ1ιοδΗΕΕφ=<781£па1иге V а! ие>
<Кеу1пй>>
<КеуКате>ит:х-ос1оризлп(ег1гиз1.сот:зссге1-кеу:2002;ит:х-ос(оризлп1ег1гиз1.сот:5ссгс(кеу:2001 </КеуМате>
</Кеу1пГо>
</51дпа1иге>
</Вшк11е>
Приложение В. Дополнение Ό. Пример Соп1еп1Кеу с отменой <Соп(еπίΚеу М-'ит:х-ос1ориз.ΐηί еПгизксот:соп1еп1-кеу:2001>
<8есге!Кеу 1б=ит:х-ос1ори5.1п1епги51.сот:£есге1-кеу:200Г'>
<КеуОа1а епсоЛпд=хт1епс £огта1=КАМ/>
<Епсгур(е(ЮаГа хт1пз=11йр://с¥сусу.су3.огд/2001/04/хт1епс#> <ЕпсгурИопМе11тос! А18ог11Ьт=Ьпр://сусусу.с¥З.О1^/2001/04/хт1епс#ае5128-сЬс/> <Кеу1пГо хт1П5=11йр://сусусу.суЗ .ог§/2000/09/хтИз1£#''>
<Епсгур1еОКеу хп11п8=”1Шр:/Лусусу.суЗ .огд/2001 /04/хт1епс#> <ЕпсгурйопМе1Ьоб А1§ог№т=,'5йр://сусу1л'.у>,3.огд/2001/04/хт1ег)с#Г8а-1_5'7> <Кеу1п1о хт1пз=Ьир:/Апт.\у3.ог§/2000/09/хи1!<131£#> <КеуМате>ит;кГогта1:изег:0001 :зсиЬа:ра1г:з11аг1пз</КеуКате>
</Кеу1пГо>
- 126 012918 <С1рЬегОа1а>
<С1рЬегУ а1ие>Е(РЦВ изег, 1)</С ΐ рЬегУа! ие>
</С|рЬегОа1а>
</Епсгур1ес1Кеу>
<Кеу1пй>>
<С|р11егЕ>а1а>
<С1ркегУа1ие>
Шифрование элемента ЕпсгурКсЮаи, содержащее шифрование Кс согласно схеме широковещательного шифрования (см. примечание по хгпкпс и широковещательному шифрованию ключей в разделе Соп(еп£Кеу) с помощью промежуточного ключа I.
</С[рЬегУа1ие>
</С1рКегРа(а>
</Епсгур£е4Са1а>
</КеуЦа(а> </5есге1Кеу> </Соп£еп1Кеу>___________________________________________________________
Приложение С
В этом приложении С приведен пример простого профиля для использования с вышеописанным протоколом автозагрузки. Кроме того, предусмотрены простая каноническая сериализация, иллюстративная маршализация ΧΜΕ, и иллюстративный \У8ЭЕ для ОсЮрик Воо1к1гар 8ОАР \УеЬ 8егй'се.
Простой профиль
В одном варианте осуществления, используется простой профиль, имеющий следующий состав:
| Имя профиля | Простой профиль |
| Алгоритм шифрования открытым ключом | Ьеер://ини.»3.огд/2001/04/хп11епс#1:ва-1_5 |
| Алгоритм подписи открытым ключом | .ог$/2000/09/хт1<1з1д#гза-зЬа1 |
| Алгоритм шифрования секретным ключом | ЪЪср: ыЗ .С1гд/2001/04/хкйепс#ае5128- сЬс |
| Алгоритм подписи секретным ключом | //имш + иЗ . ο^д/2000/09/xт1άΕ^д#^ιтас- зЬа1 |
| Алгоритм дайджеста | Мер; //им«-м3 .огд/2000/09/хт1(181д#аЬа1 |
| Формат сертификата | Х.509 (версия 3) |
| Маршализация сообщений | Простая маршализация ХМЬ 1.0 |
| Минимальный размер нонса | 16 байтов |
| Каноническая сериализация объекта | Простая каноническая сериализация 1.0 |
Простая каноническая сериализация 1.0.
В одном варианте осуществления вышеописанная простая каноническая последовательность байтов, используемая в простом профиле, состоит в построении последовательностей байтов из значений полей объектов в сообщениях. Каждое сообщение и каждый объект состоит из одного или нескольких полей. Каждое поле является либо простым полем, либо составным полем.
Простые поля могут быть четырех типов: целое число, строка, последовательность байтов или массив полей. Сложные поля состоят из одного или нескольких подполей, каждое из которых может быть простым или составным.
В одном варианте осуществления существуют следующие правила построения канонической последовательности байтов для каждого типа поля:
Сложные поля
| Поле 0 | Поле 1 | Поле 2 |
Каноническая последовательность байтов является сцепкой канонических последовательностей байтов каждого из подполей (необязательные поля не пропускаются, но сериализуются согласно правилу для необязательных полей).
Массив полей
Счетчик полей Поле 0 Поле 1 ...
Счетчик полей закодирован в виде последовательности из 4 байтов в обратном порядке следования байтов, после него следуют канонические последовательности байтов каждого из полей. Если счетчик полей равен 0, то после 4-байтового счетчика полей ничего нет (в этом случае, все 4 байта имеют значение 0).
- 127 012918
Целое число [ ίο | 11 Д 12 | 13 |
32-битовое знаковое значение, закодированное в виде последовательности из 4 байтов, в обратном порядке следования байтов.
Строка
| Счетчик байтов | байт 0 | байт 1 |
Строка представлена последовательностью 8-битовых байтов в кодировке ИТР-8. Счетчик байтов закодированной последовательности байтов кодируется в виде последовательности из 4 байтов в обратном порядке следования байтов. После счетчика байтов следует последовательность байтов строки в кодировке ИТР-8.
Последовательность байтов
| Счетчик байтов | байт 0 | байт 1 |
Счетчик байтов закодирован в виде последовательности из 4 байтов в обратном порядке следования байтов (если последовательность байтов пуста, или соответствующее поле пропущено, счетчик байтов равен 0, и после 4-байтового счетчика байтов нет никаких байтовых значений). Каждый байт кодируется как есть.
Простая маршализация ХМЬ 1.0
Схема 8ппр1еВоо1Рго1осо1.хкб <х5:5сЬетахт!п5:х£=*,ЬПр://ч7ту.^3.ог§/2001/ХМЬ8сЬетз'’ е1етеп1ГогтОеГаи11=яиаИбе<Г’> <х5:е1етепТ пате=Воо|51гарКе91|$£ТМе5$аёе,’>
<ха:сотр]ехТуре>
<хз:зедиепсе> <х5:е1етеп< ге<=’Ъсю151гарКе9иф$Г> </хз:зечиепсе>
<Х8:аШчЬ«Ле пате=РгоЮС0Г' 1уре=’'хз:81пл§ и5е=''геяшге<Г/> <х8:аПпЬШе пате=”Ргой1еи (уре='*х8:з1пп§'' изе=нгечшгесГ> <х5:айпЬи1е пате-’Уегзюп” 1уре=,’хз:с1ес1таГ и5е=гедшге{Г/> <хз: сотркхТу ре>
</х5:е1етеп1>
<хз:е1етеп< пате=’'Воо151гарКеяие5Г>
<хз:сотр!ехТуре>
<хз:зечиепсе> <Х8:е1етеп1 ге₽='’8е88юп1£Г7> <Х5:е1етеп1 ге^ТгизтГ)ота1п1' тахОссигз=ипЬолпйес1''/> </Х8:зе9цепсе>
</х8:сотр1ехТуре>
</х$:е1етел1>
<х8:е1етеп( пате=Г1СЬа11еп^еКех]иезгМе5зазем>
<Х8:сотр1ехТуре>
<х$:8ечиепсе> <хз:ектеп1 ге^’'СЬа11еп§екедиезО </хз:зечиепсе>
</хз:сотр|ехТуре> </хз:ектепг>
<хз:е1етеп1 пате=’,Ска11еп2еЯецие51,’>
<х5хотр1ехТуре> <х8:зечиепсс> <хз;с1етеп1 ге!=СЬа11еп£,е,,/> <х5:е1етеп1 ге£=|’81£па1иге17> <х5:е1етеп1 геГ=,'Сег11йса1еСЬа1П,’/> </х8:8ециепсе>
</х5:сотр1ехТуре>
</хз:е1етеп1>
<х5:е1ете1йпате=1’СЬаИеп5еКе8роп5еМе8за£е'’>
<Хз:сотркхТуре>
<хз:зес|иепсе>
<х8:ектеп1 ге£=8е531опКеу'7> <хз:екте1Н ге1=Епсгур1е0СНаПеп|еКе8рол5е,|/> </х$:8ечиепсс>
</х8:сотр1ехТуре>
</хз:е1етел1>
<хз:ектеп< пате=Епсгур1е<1СИа!кп£сК.е5ропзе 1уре=хз:Ьазе64Втагу,7> <хз:ектеп( пате-'Ска11еп§еКезроп&е>
<хз: сотр 1ехТу ре>
<х5:зедиепсе> <хз:ектеп( Γβί^'Ό1ί$ηΐΙηίο'7> <хз:е1етеп( ге1=СЬа11еп£е’’/> <хз:е1етеп< ге£=8е5зюпКеу/> <хз:е1етеп1 ге£='г5|£пагиге/> </х8:8счиепсс>
</хз:сотркхТуре>
</хз:е1етеп1>
<х5:е1етеп1 пате=пС11а11еп§е>
<хз:сотр1ехТуре> <Х8ГЗСЧ11€ПСе> <хз:е1етеп1 ге^='’Соок1е’'/> <х8:е1етеп1 ге^=,гМопсе”/> <хз:ектеп1 геР=,18е83юп1с1/> <хз:ектеп1 ^еί^Έπс^уρίюηΚеу’, 1П1пОссигз-0/> </х&:5ециепсе>
</хз:сотр!ехТуре>
- 128 012918 </хз:е1етепГ>
<х£ :е1 ет еп( пате=Воо1з(гарВ.е5роп5еМезза§е>
<хз:сотр1ехТуре>
<хз:зсдиспсе>
<хз: е1етеп( ге Г=Епсгур1е4Воо:з1гарВезропзе />
</хз:зечиепсе> </хз:сотр!ехТуре>
</хз:е1етеп1>
<хз:е1етеп1 пате=Епсгур(е<1Воо1з1гарВезропзеф' 1уре-'хз: Ьазеб4В1пагу7> <Х5 :е! етеп( пате-'В<хЛз(гарК.езропзе >
<хз:сотр1ехТуре>
<хз:зедиепсе>
<хз:е1етеп1 геГ-ф'8еззюп1<Г/>
<хз:е1етепГ ге*=’'0а1а'7>
<хз:е1етеп( геЕ81£па1иге/> </хз:зедиепсе>
</хз:сотр1ехТуре>
<Ли:е1етеп1>
<хз: е1 етеп! пате= ф'ЕпогКезропзеМезза§е,ф>
<хз:сотр 1ехТ уре>
<хз:зедиепсе>
<хз:е1етеп( геЕЕггогК.езропзе/> </хз;зедиепсе>
</хз:сотр1ехТуре>
</хз:е1етеп!>
<хз:е1етеп( пате=ЕггогКезропзе (уре=’фхз:з1г1пй/>
<хз:е1етеп( пап1е=СегС|Г1са1еСйа1п'ф>
<хз:сотр1ехТуре>
<хз:зеяиепсе>
<хз:е1етеп1 ге(=Сегбйса1е тахОссигз=ипЬоип(1е0/> </хз:зедиепсе>
<хз:а11нЬи1е пате=ТгизЮота1п 1урс=хз:згпп§ изс=гсдшгсс1/> </хзхо1пр1ехТуре>
</х5:е1етеп(>
<х$:е1етеп( пате=Сегййса(е|ф 1уре='фхз:Ьазе64Втагу’7>
<хз:е1етеп1 пате=СПеп11п(о>
<хзхотр!ехТуре>
<хз:зсчиспсе>
<х5:е1етеш ге₽=|фАйпЬи(е>
</хз;зедиепсе> </хз:сотр!ехТуре>
<7хз:е1етеп1>
<хз:е1етеп1 пате=ф'АйпЬи1е 1уре=,фхз:з1ппй/>
<х$:е1етеп1 пате=ф|Соок1е|ф 1уре=хз:Ьазе64В1пагу/>
<хз:е1етеп1 пате=ф'Оа£а 1уре- 'хз;Ьазе64Втагуф7>
<х$:е1етеп( пате=ф|ЕпсгурйопКеу’ф 1уре=хз:Ьазе64В|пагу’7>
<хзх1етеп( пате=ф'Мопсе 1уре=ф'х8:Ьазе64Втагу/>
<хз:е1етеп1 пате=ф,8еззюп1(Г (уре=хз:з1г1п§/>
<хз:е1етеп( пате=8ез51опКеу’ф (уре=хз:Ьазе64В1пагуф'/>
<х5;е1етеп1 пате=81£па(иге'ф (уре~ф|хз:Ьазе64Втагу’7>
<хз:е1етеп( пате=ф,Тгиз1Оотат 4уре=ф|хз:зСппд'7>
</х5:зсЬета>
Пример:
<Воо{51гарПедиез1Мезза£е Рго(ооо1=Ос£ориз31тр1еВоо1,ф Ргой1е=ф|5|тр1еРгой1е Уегзюп=фф1 ,0> <В ооЫгарКециезО <8езз1оп] сЕзоте-итяие-зеззюп-ί ά-ООО 8</£еззюп14>
<Г гизФотат>11гп: х-ос(ориз. ί пГегйизр сотгзсиЬа: Ьоо1 Лгизкботат: ГезЮО 1 </Т тз(Оота1п> </Воо1з1гар1<едие51>
</Воо(зГгарКедиез1Мез8азе>
<СЬа11еп8еВедие81Меззаде>
«ЗИаПеп^еКедиезО <СКа11еп§е>
- 129 012918 <Ссюк1е>с29128116πι1χά\¥υΐο2νζο2]ν6ί 1 ргСО\уМОА4</Соок1е>
<Νοικε>Μν5νΐν73οχο5β+§ϊ3θ.ΓΡ8ζ)===</Νοης6>
<8езз1оп1<1> зоте-иш ηιιβ-5€33ίοη-ίζ1-0008</8еззк>п1<1>
<ЕпсгурйопКеу>
ΝΠαίΜΑθσσ8ρ08Ι6300ΕΒΑρυΑΑ4αΝΑθσΒίρΚΒ^6ρΜΥ4νν·ν£Τ1ννΡΤοίΝ·νΜΙίΤΙλνΟί4ΡΖΡί7Βεζ€ίΥ 9ёх51Обатп+ЕКРя1пЗз5ХСК5гК-киуоН7С0рс38ЬоЬиЬХО6иТ5гУ5хЖКО8х2Ти5О215А1(1с!8гЛА£Р9Ьа ΟΟΜί5Κ<2Ρ9νν74Β2εΐ/ΜηιΥΗα41ίχ 1 ίυΐΙν0ζ\νΐΚπι8ρ>1§ΗΟ8ί/ρΐϋΑΟΑΒ </Епсгур(юпКеу>
</СЬа11епёе>
<8!§па1иге> Оз\)УРЗуРТ36гЗеЦ2£1|1и87хр5л¥2е171ТзА1/¥О13(Х+р81греКА(ч2ВТгН01Ас1ОогРЬуг1¥НПапс си19/г1п183Е>т52ЪОХЬ211гЬгЬХаа1СРРЗУР18ТКРиа2иСУСЕА)¥Т1Ъ0и№1пТКГ>ГтВ4/66Н05х Е>ССух<}зс1РгЬ8Кк<5руОЕ= </81§па1иге>
<Сег1|1ка1еСйат ТгизЦ)ота1п=ит:х-ос1ориз.1П1ег1гиз1.сот:зс1|Ьа:Ьоо1:1ги51ч1ота1П;£ез1001 >
<Сегй1ка1е>
МПС. конечный сертификат сущности —>
</Се«|Яса1е>
М1ГО.промежуточный сертификат — >
<Сегййсаге>
МНЕ.. .<!— промежуточный сертификат -->
</Сегййса£е>
<СегбйсаЩ>
МПО...<!— сертифицирутэти цепи непосредственно доверенному анкеру ->
</Сегййса1е>
</СегНГ1сагеСйат>
<Сйа 11еп§еКеч исз1>
</СЬа11еп£еКечиез£Мезза§е>
<СЬа11еп8еКезропзеМе8за§е>
<8езз10пКеу>
РЫсРТ2= 1 з\У7оК21 а+НАЗ<1Кт2ег4рк4<) ΑίΕΖνηΈϋ ν/ΖΟΖΤΝ2§2Υ«Ο0\νΟΚ42190ΧΟΕ3υ6ιιΐΚπιθΓη8ίΕ ΗΥ151 и4сМРакеЗСхсчиуУН63у/7тРН0я1Оос1-О1щКе9еО№2КНаЗ 5Π1ΪΚ5 8ИР2 Α/ο\νΖΗά4№ηΐ4Λν8Μν/Μϋ Оп38ЦШба8/21= </8еззюпКеу>
<Епсгур1е4СЬа11еп8еКезроп5е>
тОСкРЕ560000о...
</Епсгур1ебС11а11еп£е1<е5ропзе>
</СЬа11 еп£еКезроп£еМе$за§е>
<Сйа11сП£сКсзропзе>
<СНеп11п(о>
<АйпЬи£е Мате=8отеАМг|Ьи1е>В1а В1а</АйпЬи1е>
</С1|еп11п1о>
<СЬа11еп§е>
<Соок!е>с29(28116πι1χάννυίο2νζο21ν0ί1 ρΖΟΟννΜϋΑ4</ΟοοΜβ>
<Νοηοβ>Μν5νΐν73οχο56+§Ϊ5θ1Ρ80==</Νοηοβ>
<8еззюп1<1>зоте· ιιηϊηικ- зеззкт- ΐά-0008</8езз10п1с1>
</СЙа11еп§е>
<8 езз юпКеу>ЬЬВ 08 ЗзОа АрР άΝ1η6ΗΡΓΐΟ==<8β33ίοηΚеу>
<81£паШге>'^УМиЕРрР41О16М1Ах(111иеИ7р/4=</818па1ш,е>
</Ска11еп§еКезропзе>
<В ооЫгарКезроп зеМезза£е>
<Епс гурГс<1Воо{зГгарЯезропзе> скХТр20+у17/| 1 рНЕауурОЬХсЮЬ...
</ЕпсгурГе<1ВооШгарЯезропзе>
</В оо!з(гарКезропзеМе.зза«е>
<Воо1з(гарКезропзе>
<8е$зюп1с1>зо1Пе-итчие-5ез5юп-1<1-0008</8ез8юп1<1>
<Оа1а>
РО94Ь\У\с£<1тУус,..
- 130 012918 <®аШ>
<81епашге>
ХчСеУКЬ4Уа¥АК911]60В5к1НО(Й1ЕрНР1Л’3»’ММЛТЬеи('чСрЕХГАВ7и2/чп)5^Ь§¥/ТООуЕОЕ5С5аУУМ¥г 1пКпОу06НЕ15б£43НизУх7(раг\уНоГгЬЗМЗеК^ХМо¥з1бхрс! Уу2ВХ 1 Ьз5 ρΤ2χ<Ι\νΒν2σΐΒ)ο7
Кг9йпЬ/ЗЬУЕО+хОа§48= </81§па1иге>
</Воо1з1гарКезропзе>
<ЕггогК.езропзеМезза£е>
<ЕггогКсзропзе Соде=6>8оте Еггог 1п£о</ЕггогВезропзе>
</ЕггогКезропзеМезза§е>
НЗОЬ для ВооЪаЪгар ЗОАР НеЬ Зеггхсе <?версия хт1 =1.0 кодировка-'υΊΤ-8?>
<!—
Этот файл м/асН описывает интерфейс для многоциклового протокола автозагрузки без определения состояний
Протокол работает следующим образом:
1. К->С: Воо(з1гарКеяиез1Мезза$е
2. С->К: СИа11еп§е1^ие81Ме8зазе
3. К->С: СЬа11еп§еКезропзеМезза§е
4. К->К: ВооШгарКезропзеМеяаце
->
< υ/зсП: Зе ίϊη ΐ(ί опз пате= Ос 1ор изВооЫгар (аг£е1№те5расе=11Нр:/Луз\ту.т(ег1ги$1.сот/зеллсе5/Ос1ор1иВоо(81гар хт1пз=Ь(1р://8с11ета8.хт1зоар.огё/м,зб1/ хт1пз:арасНезоар=Н11р:/7х1п1.арас11е.ог^'хт1-зоар’1 хт1пз:1тр1=пПр://ц,\¥1У.т1ег1гиз1.соп1/5етсез/Ос1оризВоо1Ягар хт 1п а: ί о (Г-'ЪИр ://ихт. ίп1ег1ги81.соп75егу|Сез/Ос1оризВ ооЫгар хт1пз:зоарепс=Ьпр://8сЬетаз.хт1зоар.оф'80ар/епсо<|1П§/ Х1п1п8:1пзГуре='Ъ11р:/Л71Л'\улп1ег1г118(.сот/зегУ1сез/Ос1ори8Воо181гар ___1________1____* 1_______/____11/1« ___I________II-____//__! I - Л. — Л /Н
Μΐιιιΐ3:ννΜΐι— ιιιψ и/»υιινιιΐΐΐ3,Λΐι иэдирлл к/ №>ии 1кир;,гэд11сша&.ыш:»иарлл£гУ¥аиизиЁф/ хт 1пз :хз<1-Ъ(1р://йгт¥.’И'3 .ог§/2001/ХМЬ8с Ьета хт1пз:оЬ=11Пр://т¥вд.1п(ег1ги8(.сот/Ос1ори5/Воо1зйэр/1.0'1 хт 1п з: пс- Ъйр:7г/улу.1 п1ег(гиЯ. сот/соге >
<изЛ:1урез>
<зсЬета (аг£егМатезрасе=вЬ(1р:/Лу\¥лу.т1ег1гиз(.сот/$ег¥ке5/Ос1ори5Воо1з1тарн χπιΙη8=ΙιΙίρ://νηντν.Μ'3.οΓ8/2001 /ХМк8скета>
<!— импорта ->
<троп патезрасе=Ь«р://ттхултеПгиз(.сот/Ос1ори5/Воо(5(гар/1.0 зсЬетаЬоса1юп=./81тр1еВоо(РгоКюо1.хз(Г/>
<!- элементы —>
<е1етеп1 пате=гедив8й1а1а>
<сотр1ехТуре>
<!— Это многоцикловый протокол без определения состояний (благодаря куки):
клиент может послать ВосЫгарКедиеЯМеззаце или
СЬаПеп^еКеропзеМезза^е —>
<сЬо1се>
<с1степ1гс(=оЬ:Воо1з1гарКе<|ие51Мез5а§е/>
<е!етеп1 ге!= оЬ :СЫ 1еп§еКезроп зеМезза^е />
</сЬо1се>
</сотр1ехТуре>
</ектеп1>
<е1етеп1 пате=гезропзе<1а(а,’>
<сотр!ехТуре>
<1— Это многоцикловый протокол без определения состояний (благодаря куки): сервер может в ответ послать СкаПсщ’еК.едисзТМезза&о о г ВоШЯгарКезропзеМезза^е ог ал ЕгтогКезропзеМезза^е —>
<сЬо1се>
<с1етеп( геЕ=оЬ:СИа11еп§еВ.с<|ие5(Мсзза§е/>
<е! етеп( ге£= оЬ :Воо1з1гарКезропзеМезва§е/>
<с! етепг гс(^ оЬ: ЕпгогКезропзеМез за§е />
</сЬо!се>
- 131 012918 </сотр1ехТуре>
</е1етепО <ЛеЬета>
<Луз<11:типы>
<!— объявление сообщения —>
сгузбктезза^е пате=1ПУокеКеянезГ>
<уге<11:рай е1етеп4=(пз(уре:геяиез1<1а1а пате=туокеКеяие51/>
</1¥5<11:те5за£е>
<т№<Л:те55а£е пате=1пуокейезропзе>
<уЫ1:раг4 е1етеп1=1пз(уре:ге8роп5е<1а1а пате=шуокеКезропзе7>
<,^яб1:тезза§е>
<!— объявление типа порта ->
<\ν841:ροιΐΤγρο пате=Ос(оризВоо(51гар>
<1У5<11:орега11оп пате-'туоке'’>
<\уз41:три( те55а§е=1тр1:1ПУокеКеяиея пате-’туокеЯеяиезГ7>
<\уз(11 : оигри! тезза§е-' ί тр I; ίη токеКезропзе пате= ίηνο кеК.езропзе/>
<Лл.з<Я:орега(юп>
</тес11:рог1Туре>
<ί- объявление привязки -->
<\ν8ά1:6ίηύίη§11ате=Ос4ори5Воо1з1гар£оарВ|п<йп£ 1уре=1тр1:Ос1оризВоо4з1гар>
<νν3ά1$03ρ:6ίηΐΙίη§ 81у1е-с1осигпеп( 1гапзрог(='Ъйр;//8сНета8.хт18оар.оГ£/воар/Ёир,7> <ууз<11:орегайоп пате=т¥Оке”>
<νν8£!13οηρ:ορβΓ3ΐίοίΐ зоарАс1юп=/>
<1¥8б1 :ίηριι( пате=1ПУокеК.еяиезг>
<з¥з<115оар:Ьобу епсосНпй;5(у1е='' пате8расс=ЬПр://',уллт¥лЫсгтгизГсот/8с™сс5/Ос1оризВооГзГгар изе-1кега1/>
<Λν3ά!;ίηριι1>
<зуз<11 :ои(ри! пате=туокеКезроп5е>
<з¥5<Я5оар:Ьо(1у епсод1п§81у1е=” патезрасе=''1111р://,\узУАУ.1п1ег1гиз1.сот/зегУ1сез/Ос1ори5Воо181гар нзе^1|1егаГ>
<Αν8ΐ1Ι:θ(ΐίριιι>
</•«361: орега1юп>
<Л¥з<11:Ь1п<Нп£>
<1- объявление службы ->
<зтеб1:зегу1се пате=Ос1оризВоо1з1гар5еппсе>
<д№с11:рои Ыпб1п$-Ίπιρί :ОсГори$Воо1з1гар8оарВт<Нп£г< пате=Ос1оризВоо1£(гар>
<\¥8<118оар:аб<1гез5 1оса1юп=Ь(1р://1оса1ко51:8080/Ос1оризВоо151гар/зегу|се8/Ос1оризВоо15(гар/> <Л*8с11:рог1>
<угес11;зепнсе>
<Луз<1 1:4ейп йюпз>
Приложение ϋ
Ниже представлен способ вычисления, не зависящий от кодирования, канонической последовательности байтов (СВ8) для объектов, который используется, в предпочтительных вариантах осуществления, при вычислении дайджестов для использования цифрового подписывания объектов. Эта последовательность байтов не зависит от способа представления или передачи объектов, что позволяет использовать одни и те же значения дайджеста и подписи в системах, где используются множественные форматы кодирования (например, ΧΜΣ, А№1), языки программирования, и т.п.
1. Алгоритм канонической последовательности байтов.
Алгоритм канонической последовательности байтов состоит в построении последовательностей байтов из значений полей. Каждое поле имеет значение простого типа или составного типа. Некоторые поля могут быть заданы как необязательные (поле может присутствовать или отсутствовать).
В одном варианте осуществления простые типы представляют собой целое число, строку, байт и логическое значение.
Составные типы состоят из одного или нескольких подполей, каждое из которых имеет значение простого или составного типа. Составные типы могут быть разнородными или однородными, в том смысле, что содержат одно или несколько значений подполей (простых или составных) разных типов (т.е., разнородные), или содержат одно или несколько значений подполей (простых или составных) одного типа (однородные).
Каноническая последовательность байтов поля получается путем применения правила кодирования к значению поля, когда поле всегда присутствует, или правила кодирования для необязательных полей, когда поле задано как необязательное. В нижеследующих описаниях правил кодирования, термин байт означает 8-битовое значение (октет).
1.1. Необязательные поля.
Если необязательное поле присутствует, его значение сериализуется как байтовое значение 1, после которого следует каноническая последовательность байтов значения поля. Если оно опущено, его значение сериализуется как байтовое значение 0.
1.2. Разнородный составной тип.
- 132 012918
Каноническая последовательность байтов является сцеплением канонических последовательностей байтов значений всех подполей (необязательные поля не пропускаются, но сериализуются согласно правилу для необязательных полей).
1.3. Однородный составной тип.
Каноническая последовательность байтов представляет собой счетчик подполей, закодированный в виде последовательности из 4 байтов в обратном порядке следования байтов, после которого следует сцепление канонических последовательностей байтов значений всех подполей. Если счетчик подполей равен 0, то после 4-байтового счетчика полей ничего нет (в этом случае, все 4 байта имеют значение 0).
1.4. Целое число.
32-битовое целочисленное значение, закодированное в виде последовательности из 4 байтов, в обратном порядке следования байтов.
1.5. Строка.
Счетчик байтов байт 0 байт 1 ~ |
Строки представлены последовательностью байтов в кодировке ИТЕ-8 (без символа конца строки). Каноническая последовательность байтов для строки состоит из (1) счетчика байтов строки, закодированного в виде последовательности из 4 байтов в обратном порядке следования байтов, после которого следует (2) последовательность байтов строки.
1.6. Байт.
8-битовое значение.
1.7. Логическое значение.
8-битовое значение: 0 означает ложь и 1 - истину.
2. Применение к объектам Ос!орик.
В одном варианте осуществления, каноническая последовательность байтов для объекта Ос!орик представляет собой сцепление канонических последовательностей байтов всех его полей, в том порядке, в каком они заданы в модели объекта.
Для разнородных составных типов, порядок полей указан в определении типа. Для однородных составных типов, порядок элементов указан в нижеследующих разделах.
Атрибуты
Поле аИпЬШек объекта рассматривается как безымянный атрибут типа Нк( (это несортированный контейнер именованных атрибутов). Именованные атрибуты, содержащиеся в значении аИпЬШек типа йк!, рассортированы лексикографически по их полю пате. Безымянные атрибуты, содержащиеся в значении аИпЬШек типа аггау, не сортированы (они сериализуются в порядке их размещения в массиве). Расширения
Внутренние расширения объекта рассортированы лексикографически по их полю '16'. В одном варианте осуществления для внутренних расширений, поле 'ех1епкюпОа!а' не используется при вычислении канонической последовательности байтов. Для таких расширений, если необходимо их включение в вычисление дайждеста с целью подписи, они будут содержать поле 'бщек!, представляющее дайджест фактических данных, переносимых в 'ех!епк1опОа!а'. Для каждого типа данных расширения предусмотрено определение, которое позволяет вычислять его каноническую последовательность байтов.
Контроллер
Ссылки на Соп!еп!Кеу рассортированы лексикографически по их полю '16' .
3. 8сиЬаКеук.
Ключи в полях 'риЬНсКеук', 'рпуа!еКеук' и 'кесге!Кеук' рассортированы лексикографически по их полю '16'.
4. Пример
С1аз8Х { ίη( ί;
ΐηί ί;
} с1а88 А { ίηί а[];
51ПП£ з;
с1а88 В ехсепбз А { {X ор!юпа1_х;}
Хх;
(з1пп£ 1оО15саг61пСапо;)
8ΐπη§ з2;
1_____________________________
Каноническая последовательность байтов экземпляра класса В, где а[] = {7,8,9}, к = АЬе, х =
- 133 012918 {5,4}, к2= и орйоша1_х отсутствует, сериализуется следующим образом:
| 3 | 7 | 8 | 9 | 3 | “АЬс” как итр-8 | 0 | Сапо(Х) | 0 |
| 4 байта | 4 байта | 4 байта | 4 байга | 4 байта | 3 байта | 1 байт | 8 байтов | 4 байта |
где Сапо^) представляет собой:
| 5 | 4 |
| 4 байта | 4 байта |
Приложение Е
Ниже приведен пример программы управления. В этом примере, лицензия указывает, что действие «воспроизведение» может быть разрешено, если состояние принадлежности (предусмотренное при регистрации) или состояние лицензии (предусмотренное при передаче лицензии) можно найти в базе данных состояний (именуемой в этом иллюстративном варианте осуществления базой данных 8еакЬе11). Лицензия также позволяет равноправному устройству запрашивать передачу лицензии. Эта передача разрешается, если два равноправных устройства находятся в данной степени близости друг от друга. Лицензия содержит агент, который задает состояние лицензии на равноправном устройстве.
В нижеследующих полях кода, ΜоνаЬ1е^ота^пΒоиηб^^сеηке.акт является главным объектом управления, МсепкеиШк/* являются помощниками для лицензии, СепепсИШк/* являются помощниками общего назначения, которые осуществляют, например, функции вычисления длины строки, сравнения строк, манипулирования стеком и/или т.п., и Ех1епбеб81а1икВ1оскРагате1егк/* содержит ΧΜΕописание параметра расширенного блока состояний и соответствующее представление в виде ряда байтов, скомпилированных из ΧΜΚ
Ε. 1 №лгаЬ1еОоп*а1пВоиш1. азт ; Имя файла: МоуаЫе0ота1пВоип0Е1сепзе. азт ; Описание: Пример перемещаемой лицензии .**************** * + *·ΜτΗΟΟ*********** +.+.**.**.*.. ******* ; константы ,βςυ 0ЕВиб_РК1ЫТ_2УЗСА1,Ь, .еди ΕΊΝϋ_3Υ30ΑΠΪ_ΒΥ_ΝΑΜΕ_3Υ30ΑΕΣ, .βςϋ 3Υ3ΤΕΜ ИО5Т_СЕТ_ОВЦЕСТ_ЗУ8САЪЬ, .ечи ЗУЗТЕМ_НОЗТ_ЗЕТ_ОВЗЕСТ_ЗУЗСАЪЬ, .ечи зиССЕЗЗ, . «Чи ГА1ШНЕ,
-ечи ЕР.Р.ОР_№_ЗиСН_1ТЕИ, .еди СОЫТА1МЕК_ЮТОКЕО_АОЦКЕЗЗ,
О -1 -6 ; включение ΐηοΐιιάθ ЗЬгСтр.азт ίηοΐυάβ Рг1пЫпЬ .аат
1пс1ийе МетЬегзЫриЬИз. азт
4пс1ис1е ЫсепзеЗ^аСеОСЫз. азт
- 134 012918 ; данные . бака (ЗекТгизкебТд.теЕ’ипскд.спЦате:
.зкггпд Зузкет.Новк.СекТгизкесГМте СекТ г из к ебТ 1те Гипск. ί опМитЪ е к :
. 1опд 0
Аскд.опСгапкес1ЫоОЫ1дак1апХЗкакиз:
. 1опд . 1олд . 1опд . 1опд . 1опд . 1опд . 1опд
Аск1оп0еп1е<1ХЗкакиз:
. 1опд . 1опд . 1опд . 1опд . 1опд . 1опд . 1опд
0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 ; глобальные флаги ; категория = Α€ΤΙΟΝ_3ΚΑΝΤΕΟ ; подкатегория ; локальные флаги ; тип времени жизни кэша ; значение времени жизни кэша ; размер списка значений = 0
0x00000000
0x00000001
0x00000000
0x00000000
0x00000000
0x00000000
0x00000000 ; глобальные флаги ; категория = АСТЮН_0ЕК1Е0 ; подкатегория ; локальные флаги ; тип времени жизни кэша ; значение времени жизни кэша ; размер списка значений = 0
ТгапзГегСгапкедРгоххтакуЫокСЬескеб:
. 1опд . 1опд . 1опд . 1опд . 1опд . 1опд .ΐποίυάβ Тгапз£егХЗкакизРгох1т1куС11ескГа11еб.азт
ТгапзкегбгапкебРгохктХкуСпескеб:
0x00000000
0x00000000
0x00000000
0x00000003
0x00000000
0x00000000 ; глобальные флаги ; категория - ΑΩΤΙΟΝ_ΟΚΑΝΤΕΟ ; подкатегория ; локальные флаги: ОЬИдакгоп и СаНЬаск Нокгсез ; тип времени жизни кэша ί значение времени жизни кэша . 1опд • 1опд . 1опд . 1опд . 1опд . 1опд глобальные флаги категория = АСТЮН'ЗЗ.АНТЕСподкатегория локальные флаги: ОЬИдакхоп и СаНЬаск Мокгсез тип времени жизни кэша значение времени жизни кэша
0x00000000
0x00000000
0x00000000
0x00000003
0x00000000
0x00000000 .1пс1ибе Тгапз£егХЗкакиеРгохкгмЛуСйескЗиссеей.азт АдепкСопкехкРакН:
.зкгкпд Оскориз/Адепк/Зеззгоп/СопкехЫб АдепкСопкехкОез1гебУа1ие:
.зкгкпд МоуеЗкакеСопкепкОС23
АдепкСопкехкУа1ие:
.гегоз 32
51пкРгох1т1куЬавкРгоЬе₽акЬ:
.зкгтпд ,’0скορиз/Αск^οη/Ρа^атеке^з/5^ηк/Ρ^с>x^Iη^ΐу/^азк₽^οЬе,^ 51пкРгох1т1куЬазкРгоЬеКези1к:
. 1опд -1
АдепкРгохктткуСЬескебРакк:
.зкг1пд Оскориз/Адепк/Рагатекегз/РгоххтккуСкескеб АдепкРгох1т1куС11ескебОа1ие:
.1опд О
СопкгоИегТатезкатрАЪкгкЬикеРакП:
.зкгкпд Оскориз/СспЬгоИег/АккгкЬикез/ГтрогЬ-ккте
Сопкго11егТ1теэкатрАккг1к>икеУа1ие:
.1опд 0 ; отладка .1£де£ ϋΕΒΟΟ
- 135 012918
СопЕгоИег. ТЕтезЕашр. Оиегу. ОеЬид:
•зЕгдпд ---------ЕпРегЕпд СопЕгоИег.ТЕтезЕатр.Сиегу--------------\п
СопЕго1.АсЕХопз.Р1ау.РегЕогт.йеЬид:
. зЕгхпд --------- ЕпЕегХпд Соп£го1.АсЕтопз.Р1ау.РегЕогт -------------\п
СопЕго1.АдепЕз.ЗеЕЗЕаЕеСопЕепЕ0023.кип.ОеЬид:
.зЕгЁпд --------- ЕпЕегхпд СопЕго1.АдепЕз.ЗеЕЗЕаЕеСопЕепЕ0023.Кип -------------\η·<
СопЕго1.АсЕтопз.ТгапзЕег.РегЕогт.ОеЬид:
.зЕгхпд ---------ЕпЕегхпд СопЕго1 .АсЕ:£опз.ТгапзЕег. РегЕогт-------------\п
СопЕго1,АдепЕз.ЗеЕЗЕаЕеСопЕепЕ0023.ОпАдепЕСотр1еЕ1оп.Сеоод:
-зЕгЕпд --------- ЕпЕегХпд
СопЕго1.АдепЕз.ЗеЕ5ЕаЕеСопЕепЕ0023.ОпАдепЕСотрХеЕЕоп --------------\п
ТгапзЕег_ОК_Ргох1п11Еу_ЫоЕ_С11ескед. ЕеЕид: .зЕгхпд ΗΗΙΗ ТгапзЕег_0К_Ргох1т1Еу НоЕСНескед Н1НН\п
Тгапз£₽гОК_₽гох1п1г у_сДескед. ОеЬид;
.зЕГ1пд Тгапз£ег_0К_Ргох1т1Еу_СЬескед #######\п
АдепЕ_Еа11иге.ОеЬид:
.зЕгхпд НИШ АдепЕ РапЛиге И|НН\п'
АдепЕ_Зиссезз.ЦеЬид:
.зЕг1пд НШМ АдепЕ Зиссезз 1ННН\п
АсЕ1оп_СгапЕес1. ОеЬид:
.зЕг1пд НШН ΑοΕίοη СгапЕед ЙНМИ\п
АсЕ1оп_Реп1ед. ОеЕид:
-зЕгхпд НШН ΑοΕίοη Оегйед ШНН\п .епдЕЕ соде ; 61оЬа1.ОпЬоад
Г
61оЬа1.ОпЬоад:
; получить ЕипсЕтопНитЬег для СеЕТгизЕедТтте ризн @СеЕТгизЕедТ±теГипсЕ1опНате
РизН ΓΙNС'_3ΥЗСАЬί_ΒΥ_ΝΑΜΕ_3УЗСАЫ.
САЬЬ оир
РЦЗН @СеЕТгизЕедТ1теГипсЕ1опНитЬег
РОКЕ
ΒΚΝ ОпЬоад_ЕаИед ; ок ризн зиссЕзз
ЗТОР ; неудача
0пЬоас1_Га ί 1 ед:
ризн ΕΑΐίυκΕ
ЗТОР ; СопЕгоИег . ТхшезЕашр. Оиегу
СопЕгоИег .Т1тезЕатр.0иегу:
. ΪΕάβΕ ϋΕΒυΟ ;отладка
РЦЗН @Сопсго11ег. Т1тсзЕйгг.р. Оиегу. ОеЬид ризн 0Евис_рншт_зузСАьь
- 136 012918
САШ βηάίΕ получить атрибут метки времени в объекте «контроллер»
РЦЗН 4 ; КеСиГпВи££ег512е (4 байта)
РСЗН @Соп£го11егТ1те5£атрА1:1:г1ЬиСе7а1ие ; КеСигпВиЕЕег (тип 1опд)
РЦЗН @Соп£го11егТ1П1ез£атрА££г1ЬиСеРа!:Ь ; Имя
РЦЗН 0 ; Родитель = корневой контейнер
РЦЗН ЗУЗТЕМ_НОЗТ_СЕТ_ОВЦЕСТ_3¥ЗСАШ
САШ
ВЕТ
СопЕго1. АсШопз. Р1ау. СНеск /
СопЕго1. АсШопз.Р1ау.СЪеск:
/ ; СопСго!.АсЕтопз.Р1ау.РегЕогт
СопЫо1. Ас£1бпз. Р1ау.РегЕогт:
; запросить пути к состоянию
ЦЗК МетЬегзМрЗгаСеРарЬ.Оиегу
ΒΚΝ АсЫоп 0еп1ес)
ЦЗК Ι,ΐοθηϊβΞ^δίθΡθΕΗ.ΟυθΓγ
ΒΚΝ Άο1:±οιι_0θηίθό . 1£с1е£ ОЕВиС ;отладка
РЦЗН @Соп£го1. АсШопз.Р1ау.РегЕогт.ЦеЬид
РИЗН 0ЕВиС_РК1НТ_3¥ЗСАЪЪ
САШ •елб1£ ; если метка времени состояния принадлежности >
; метки времени контроллера
ЦЗК Μ«£α6θΓ5ΐ\ίρ3ύ3ύ6ν31υθ.Оиегу
ΒΚΝ АсС1ОП_0еп1ес1
ЭЗР. СопШоШег .ТХтезЕатр.Оиегу
ΒΚΝ Ас1;1оп_Оеп1 ей
РЦЗН вМетЬегзЫрЗЕаЕеУаШе
РЕЕК
РиЗН 0СопЕго11егТ£тез1:атрАШг1Ьи£е7а1ие
РЕЕК зив
ΒΚΡ Ас£1оп__Сгап1:ес1 ; нам не нужно проверять состояние лицензии ; в этом случае ; мы просто проверяем, присутствует ли состояние
ЦЗН ШсепзеЗЬаЕеУаХие.Сиегу
ВР.М Αο£ίοη_Οοηίθά
АсЕ1оп_Сгап£ей:
, Х£<1е£ ЦЕВЦС ;отладка
РЦЗН @АсЫоп Сгап£ес1. ОеЬид ризн 0ЕВис_Рк1кт_зузсАць
САШ . епеИЕ
РЦЗН ЭАсЫопйгапСеЦНоОЬИдаЫопХЗкакиз рцзн зиссЕзз
ЗТОР
- 137 012918
АсЫоп_Веп1ес1:
,ίίάβί ОЕвис ;отладка
РОЗИ @АсС1оп_Цеп1ес1.ВеЬид ризн 0ΕΒυσ_ρκΐΝτ_3Υ3θΆΐ,Ε САЬЬ . епсИ£
РИЗН @ЛсИ опСег1 ί ΐ;ίΓΧ31;.·-ι 1:из ризн зиссезз
ЗТОР ; Сог)Ьго1.АсЫопз.Тгапз£ег.Сбеск
Сопкго1. Ас£.1опз. Тгапз£ег. СЬеск :
Г ; Сспбго1.Асбхопз.ТгапзЕег.Рег£огт
Сопбго!. АсЫопз.Тгапв£ег.Рег£огт:
; запросить пути к состоянию
ЛЗК МетЬегзМрЗбабеРабН.Сиегу
ΒΚΝ пс£1оп_0еп1ед
Л5В ЫсепзеЗ^акеРаЫ!. Оиегу
ΒΚΝ АсЫоп_Оеп±ед . 1£бе£ ОЕВиб ;отладка ₽изн @Сопбго1. АсЫопз . ТгапэСег. РегГогш.ОеЬид ризн 0Евис_РК1йт_зузсАьь саг т .еп41£ ; получить близость, которая была проверена в последний раз
РВЗН 4 ; Ке£игпВц££ег312е риЗН @31пкРгох11й1СуЪаз£РгоЬеКези1б ; к.еситви££ег
РиЗН @31пкРгох1т1£уЬаз£РгоЬеРа11£1 ; Имя ризн 0 ; Родитель = корневой контейнер ризн ЗУЗТЕМ_НОЗТ_СЕТ_ОВЛЕСТ_ЗУЗСАЬЬ
САЬЬ ; если объект невидим, близость не была проверена.
; результирующий агент (см. файл Тгапз^егХЗбабизРгохьтьбуСйескГаИед. хп>1 ; в строке 23). Агент сможет удостовериться, что агент является частью ; домена, до задания состояния
ВРИ Тгапз£ег_0К_Ргох1т1£у_Мо£_С11ескес1 ; проверить, что близость была проверена в последние 10 минут
| 6КОР | ; мы | знаем, | что | ίά | типа есть | 1опд | |
| ОКОР | ; мы | знаем, | что | размер равен | 4 | ||
| Ρ05Η | вбебТгизбедТхтеГипсбхопКитЬег | ||||||
| РЕЕК | |||||||
| САЬЬ | |||||||
| ЗИАР | |||||||
| ϋκορ | ; нам | ί просто | нужно | значение | |||
| ризн | @31пкРгох1п11£уЬаэ1:РгоЬеВези1С |
РЕЕК зив ризн 10
ЗНАР зив ; в последний раз близость была проверена более 10' назад: то же самое, ; как если бы она не проверялась вовсе (см. выше)
- 138 012918
ΒΚΝ Тгапз£ег_0К_Ргох1т1 Еу_Ыо£_Сйескес1 ; близость проверена успешно
-ΐ£άβ£ СЕВЦС ;отладка
РИЗН @Тгапз£ег_0К_Ргохл-ппЛу-Сйескеб. ОеЬид
РИЗН 0ЕВ0С_РР!1ЫТ_5¥ЗСАЫ.
САЬЬ .βηάΐί
Ризн бТгапэЕегСгапЬейРгохттхСуСйескед ризн зоссезз
ЗТОР
Тгапз£ег_0К_Ргох1таСу_Ис1:_СЬескеЬ:
.ί£άθ£ ВЕВиС ; отладка
Ризн @Тгапз£ег^0К_Ргох1т1£у_НоС_СЬескес1.Оекис
РиЗН 0ЕВиС_РК1КТ_3¥ЗСАЬЬ
САЬЬ .βηάίί ; передать обратно ВипАдепЬОпРеег ОЬИдаЫоп (указывающий, что ; близость не была проверена) и 0пАдепЬСотр1еЫоп СаНЬаск Р113Н @Тгапз£егСгапбе<1Ргох1т1ЬуМоЬСЬескес1 ризн зиссЕзз
ЗТОР ; Сопкго! .Адепкз . ЗекЗЬа1:еСопЬепк0023.Кип ί
СопЬго1.АдепЬз.ЗеЬЗЬаЬеСопЬепЬ0023.Вип:
; запросить пути к состоянию
ОЗК МешЬегзЫрЗЬакеРаЬЬ.Онегу
ΒΚΝ АдепЬ Вип_Еа11ес1
ЦЗВ ЫсепзеЗкаЬеРаЬЬ .Оиегу
ΒΚΝ Адеп£_Вип_Еа11еб . 1£<4е£ ОЕВОС отладка
Р05Н @Сопбго1.АдепСз.ЗеЬЗСаСеСоп£епь0023.Еип.ОеЬид
РОЗН 0ЕВиС_РВИТГ_5¥ЗСАЬЬ
САЪЕ . епЬ1£ ; если равноправное устройство находится в домене, ; нам ничего не нужно делать
ДЭР. МетЬегзМр. СЬеск
ΒΚΖ Адеп£_3иссезз ; сЬеск Ылаь кЬе сопкехб £з зек
РИЗН 32 ; КекигпВи££ег31ге
РОЗН еАдепкСопкехкУакие ; Ке£игпВи££ег
РиЗН ОАдепЬСопСехЬРакй ; Имя
РИЗН 0 ; Родитель = корневой контейнер
РНЗН 5Υ3ΤΕΜ НОЗТЗЕТОВиЕСТ ЗУЗСАЬЬ
САЬЬ ; сЬеск ЬЬе гезиЬЬ
ΒΒ.Ν Адеп£_Вип_ЕаЬ1еЬ
ОВОР ; мы знаем, что ΐά типа есть з£гд.пд
ОВОР ; размер нам не важен
РИЗН @Адеп£Соп1:ех(:Уа1ие
РиЗН @АдепЬСопЬехЬ0ез1ге<37а1ие
- 139 012918
Р. зсгеч ; убедиться, что мы в хорошем контексте
ΒΚΝ Адеп£_Вип_Еа11е0 ; проверить, успешно ли источник проверил приемник на близость
РиЗН 4 ; РебигпВи££ег51ге
РиЗН @Адеп£Ргох1тИ:уСЪескес1Уа1ие ; Ке£игпВи££ег
РиЗН (ЗАдепбРгохгтьбуСЬескейРабН ; Имя
ΡϋΞΗ 0 ; Родитель = корневой контейнер
РИЗН 5Υ3ΤΕΜ НОЗТ ЗЕТ ОВСГЕСТ ЗУЗСАЬЕ
САШ, ; проверить результат
ΒΚΝ АдепЬ Кип ЕаШей
ОКОР ϋΚΟΡ
Ρϋ3Η @АдегтЬРсох1га1£.уСЬ.ескес1Уа]-ие
РЕЕК
МОТ
ΒΚΖ АдепСЗеб Збабе
Адепб_ Г<ип Гас1ес1;
.1Ме£ ϋΕΒυΰ ;отладка
ΡΙΙ3Η @АдепЬ_Га11иге. ОеЬид ₽изн СЕВиЗ_РВ1ЫТ_5УЗСАЪЬ САЬЬ .βηάίί ризн о ризн о ризн рдтьикЕ
5Т0Р
Адепс_3еб_3баЬе:
; задать состояние
ЭЙК ШсепзеЗЬабе. ЗеЬ
ΒΚΝ АдепЬ_Рип_Га11ед
Адепб_3иссезз:
.ί£άθ£ ОЕвис ;отладка
РиЗН @Адеп!:_5иссезз .РеЪид ризн 0ЕВиЗ_РВ1ЫТ_ЗУ5СА1Щ САЬЬ . еп<Н£ ; успех ризн о ризн о ризн зиссЕзз
ТОР ; этот параметр приложение всегда ; должно задавать при приеме агента ; мы знаем, что ίώ типа есть 1опд ; мы знаем, что размер равен 4 ,· КеЬигпВ1оскЗххе ; КеЬигпВХоскАсЩгезз ,· Кези1£Сос1е ; ЙеЬигпВ1оск312е ; Ке£игпВ1оскА0дгез5 ; Кези1ЬСос1е ; обратный вызов Соп£го1.Адепбз.ЗеЬЗЬаСеСопЪепс0023.ОпАдепЬСотр1еЫоп ; (типа КЕЗЕТ)
Соп£го1.Адепбз.Зе£8£аЬеСоп£епС0023.0пАдеп£Сотр1еЫ.оп:
,ί£άο£ ϋΕΒϋΟ ;отладка
РНЗН @Соп£го1. АдепСз . ЗеЬЗЬаЬеСопЬеп1:0023 . ОпАдепьСотр1еЫоп. РеЬыд ризн С'Евис _рк1:1т_5угсАьь
САЬЪ
- 140 012918 .еп<11Е ; проверить, что код результата агента ОК ,· стек это:
; ... АдепСРези1ЕСойе СотпрЗеШопЗЪ
ОНОР ϋΚΟΡ
ΒΚΝ АсЕ1оп_0еп1ес1
ΒΡ.Ν ΑοΕίοη_Οθηίβά
ЕизСойе АгдитепЕзВ1оск51ге Соокхе ; нам не нужны куки ; нам не нужен размер блока ; аргументов ; если выполнение агента не удалось, ; неудача ; то же саме, как если бы агенту ; не удалось задать состояние на ; равноправном устройстве ; успех
РОЗН еАсЫопСгапЕедКоОЬИдаЫопХЗкакиз ризн зоссезз
ЗТОР
АдепЕ_Сотр1еЕ1оп_Га11ед:
ризн РА1ьикЕ
ЗТОР ,· экспорты • __________ _________ .ехрогб С1оЬа1.ОпЬоай •ехрогб СопЕго! .АсИопз . Р1ау.СЬеск .ехрогс СопЪго1 .АсЫопз . Р1ау. РегЕогт . ехрогб Сопбго1.Ас Шопа .ТгапзЕег, Сйеск .ехрогб СопЕго1.АсеЕопз.Тгапзбег.РегЕогт .ехрогб СопЕго1.АдепЕз.ЗеЕЗкаЕеСопЬепЕ0023.Еип •ехрогб Сопбго1.Адепбз.ЗеЕЗЕаЕеСопСепб0023.0пАдепЕСошр1еС1оп
Б. 2 ЫсепаеиЪИз
Е.2.1 Ъхсеп8еЗЪа-Ьеиъ±1а. азт г
; Имя файла: ШсепзеЗЬайеШШз. азт ; Описание: Утилиты для состояний лицензии г ζ
Г ; данные .бака
ЫсепзеЗЪаЬеРаЬЬСопЬгоТАЬЬгхЬиЬе:
, зйгхпд ОсЬориз/СопЬгоХ/АЬЬгхЬиЬез/ЫсепзеЗЬаЬеРаЫл ЫсепзеЗЬакеРаьЬ:
.гегоз 256
ЬхсепзеЗЬаЬеУаХие:
. 1опд О ; отладка
ЫсепзеЗЪаЪеРаЬЬ.фиегу. ОеЬид:
| ,зЕг1пд ---- ----\п | ------ЕпЬегхпд ЫсепзеЗЪаЬеРаЫз. фиегу |
ЫсепзеЗЪаЬеУаХие. Оиегу.ОеЬид:
| .зЕгхпд ---- -----\п | ------ЕпЬегхпд ЪхсепзеЗкаЕеУаХие.фиегу |
ЪхсепзеЗЬаЕе.Егазе.ОеЬид:
- 141 012918 . зкгупд ---------Епкегупд ЬУсепзеЗкаке.Егазе \п
ЬхсепзеЗкаке. Зек.ЭеЬид:
. зкггпд --------- Епкег1пд ЫсепзеЗкаке. Зек \п • Ш » ===ϋ5ί=5ί = ^ = = = ; код . сойе
Г ; ЫсепзеЗкакеРакЬ.фиегу <
ЪусепзеЗкакеРакЬ.Очесу:
;отладка
Р83Н @ЫсепзеЗкакеРакк. Оиегу. ЦеЬид ризн 0Евис_РК1мт_зузсАьь
САЫ>
Ризн 256
КекигпВи££ег31ге
РЭЗН @Ысепзе8какеРакЬ
РОЗИ @Ъ1сепзе8какеРакЬСопкго1Аккг1Ьике ризн О ; КекигпВи££ег ; Имя ; Родитель = корневой ппои гиил
САЬЬ
КЕТ ; Ы.сепзеЗкакеУа1ие .<2иегу г
Ысепзе5какеУа1ие. Оиегу:
;отладка
РиЗН 0Ысепзе8какеУа1ие.Оиегу. ВеЬид ризн вЕвис_рр1ыт_зузсАВЬ
САЬЬ ризн 4 байта)
РС13Н @ЫсепзеЗкакеУа1ие
1опд)
Р05Н @Ысепзе5какеРа£Н ризн О контейнер
РиЗН 8У8ТЕМ_НО8Т_<ЗЕТ_ОВ^СТ_5¥5САЬЪ
САЕЪ
КЕТ ; КекигпВи££егЗ£ге (4 ; КекигпВи££ег (тип
Имя ; Родитель = корневой ; Ъ1сепзе8каке.Егазе
- 142 012918 ; Размер объекта ; Тип объекта
Удалить контейнер
Имя ; Родитель = корневой
ЫсепзеЗбабе, Егазе:
;отладка
РНЗН ЗЫсепзеЗбабе. Егазе. ОеЬид ризн ОЕВиС_РК1КТ_8У8САЬЬ
САЪЬ ; удалить локальное состояние ризн о (контейнер) ризн о (контейнер) ризн о
РиЗН @ЬбсепзеЗбабеРаб11 ризн о контейнер
РиЗН ЗУЗТЕМ_НОЗТ_ЗЕТ_ОВ7ЕСТ_ЗУЗСАЬЬ САЬЬ
КЕТ ; ЫсепзеЗбабе. Зеб
ЫсепзеЗбабе.Зеб:
; отладка
РиЗН ЭЫсепзеЗбабе. Зеб. беЬид ризн 0Евие_РВ1кгг_зузсАьъ
САЬЪ ; задать состояние ризн О (контейнер) ризн О (контейнер)
РбЗН ΟΟΝΤΑΙΝΕΗ_Ι6ΝΟΚΕΟ_ΑϋϋΚΕ33
Ризн ЭЫсепзеЗбабеРабН ризн о контейнер ризн ЗУЗТЕМ_НО8Т__ЗЕТ_ОВ6ЕСТ_ЗУ8САЬЬ
САЬЪ ; Размер объекта ; Тип объекта
Имя ; Родитель = корневой
ВЕТ
Е.2.2 МвтЬегзЬ±риЪ±1з.авт • 4с4с4с4с4с4с4с4с4с4г4с4с4!4с4с4с4с4с4с4с,Л4с4с4(4с4с4с4с4:4с4с4с4(4с4(4с4(4с4!4с414с4с4с4с4с4с4с4с4!4с4с4с4с4е4с,к4с г
; Имя файла: МетЬегзМрибИз. азт ; Описание: Утилиты для принадлежности к широковещательной услуге * Чг Ч? Чс Чг 4с Чг 4с 9? 4с Ч· Чг 4с 4с 4с 4с 4с 4с 4с 4С 4с 4 * Λ Чг Λ Чс 4с Чг Ч * Ч * Че * 4С * 4с 4с 4с 4с Че Чг Ч 4с 4с 4с Ч Ч Ч 4с 4с 4с Ч Λ Ч Ч Ч чк· * ; данные . баба
МетЬегзЫрЗбабеРабЬСопбгоЪАббгЪЬибе:
- 143 012918 . зЬг±пд ОсЬориз/СопЬгоЬ/АЬЬгбЬиЬез/МешЬегзЫрЗЬаЬеРаЬЬ МетЬегзЫрЗЬаЬеРаЬЬ:
. гегоз 256
МетЬегзЫрЗЬаЬеУаЬие:
.1опд О ; отладка тпЬЗЬгОиЬриЬ:
.зЬгтпд .............
МетЬегзЫрЗЬаЬеРаЬЬ. йиегу. ОеЬид:
.зЬгтпд ---------ЕпЬегапд МетЬегзЫрЗЬаЬеРаЬЬ. биегу----------\п
МетЬегзЫрЗЬаЬе7а1ие. Оиегу. ОеЬид:
.зЬгапд ---------ЕпЬегхпд МетЬегзЫр8ЬаЬеУа1ие.(2иегу--------\п
МетЬег зЫр. СЬеск. БеЬид:
. зЬггпд ---------ЕпЬегхпд МетЬегзЫр. СЬеск-------------\п
МетЬегзЫр_СЬеск_Зиссезз. ОеЬид:
.зЬггпд ####### КетЬегзп.тр СЬеск Зиссезз МетЬегзЫр_СЬеск_Га11иге. ОеЬид:
. зЬЫпд ####### МетЬегзЫр СЬеск Га11иге МетЬегзЫрРаьЬ. ОеЬид:
.зЬг£пд МетЬег зЫрЗЬаЬе раЬЬ:
МетЬегзЫрСеЬОЬзОиЬриЬ. ОеЬид:
. зЬЫпд МетЬег зЫрЗЬаЬе дек объект возвращает: МетЬегзЫр_Ехр1гед. ОеЬид:
.зЬг1пд МетЬегзЫрЗЬаЬе Ьаз ехрЬгеб. СЬеск ЬЬе Уа1ие о£ ЬЬе МетЬегзЫр ЗеаЗЬеН Ьокеп адагпзЬ ЬЬе местное время. ЫеиНпеЗЬЫпд:
.зЬгбпд \п соде ; МетЬегзЫрЗЬаЬеРаЬЬ. ()иегу
Г
МетЬегзЬарЗЬаЬеРаьЬ.Сиегу:
;отладка
РОЗН @МетЬегзЬ1рЗЬаЬеРаЬЬ. <2иегу. ОеЬид ризн 0ЕВиС_РЕ1ЫТ_3¥ЗСАЬЬ
САЬЬ ризн 256 ;
РеЬигпВи££ег51ге
РОЗН @МетЬегзЫрЗЬаЬеРаЬЬ ; ВеЬигпВи££ег
РиЗН @МетЬегзЫрЗЬаЬеРаЬЬСопЬго1АЬЬг1ЬиЬе ; Имя
РиЗН 0 ; Родитель = корневой контейнер ризн 3Υ3ΤΕΜ_Η03Τ_0ΕΤ_0ΒσΕ0Τ_3Υ30Α1Β
- 144 012918
САЬЬ
ВЕТ ; МетЬегзЫрЗ£а£еУа1ие. Оиегу г
МетЬегзЫр8£а£еУа1ие. Оиегу:
;отладка
Ризн 0МетЬегзМрЗ£а£е7а1ие. Оиегу. РеЬид
РиЗН ВЕВиС_РР1ЫТ_ЗУЗСАЬЬ САЬЬ ризн бМетЬегзЫрРаЬЬ. ОеЬид ризн 0Евис_РЕ1ыт_зузсАьь
САЬЬ ризн @МетЬег8П1рЗРаРе₽аРП ризн ВЕВиС_РК1ИТ_ЗУЗСАЬЬ
САЬЬ
Ризн @Йеиг11пе8£г1пд ризн 0ЕВиС_РК1МТ_5У5САЬЬ
САЬЬ ризн 4 байта)
Ризн @МетпЬегзЫрЗ£а£е7а1ие 1опд)
Ризн @МетЬегзЫрЗ£а£еРа£Ь ризн о контейнер ризн 5У8ТЕМ_НОЗТ_СЕТ__ОВ6ЕСТ_ЗУЗСАЬЬ САЬЬ ; Ке£игпВи££ег31ге (4 ; Ке£игпВи££ег (тип
Имя ; Родитель = корневой ризн @МетЬегзН1рСе£ОЬ]Ои(:ри£. ОеЬид ризн □Евис_РЕ1кт_зУЗСАЬь
САЬЬ ; печатать результат - сначала преобразовать ίη£ в з£г1пд сир ризн @1п£3£г0и£ри£
Αϋϋ
ЗИАР
₽. рггпЫпб ; вызвать печать результата ризн @1п£3£гОи£ри£ ризн оЕвис_Рк!нт_зузсАьь
САЬЬ ризн @Кеы11пеЗ£г2.пд ризн 0ЕВиС_РК1МТ_8УЗСАЬЬ
САЬЬ
РЕТ ; МешЪегзЫр. СЬеск
- 145 012918
МешЬегзЫр. САеск:
;отладка
РСЗН бМешЬегзЫр. СЬеск. ОеЪид
Ρϋ3Η ОЕВиС_РК1ЫТ_5УЗСАЬЬ
САЬЬ ; запросить состояние принадлежности
33В МетЬегзИ1рЗ'Ьа1:е7а1ие. Зиегу ; проверить успешность
ВЕК МетЬегзЫр—СЪ®ск_Га11ес1 ; проверить, что время < извлеченного в состоянии принадлежности
РОЗИ @МетЬегз1-1±р31:аЬеУа1ие ; метка времени
РЕЕК риЗН @СеЬТгиз1:ес1Т11пеЕипсЫопЫитЬег
РЕЕК
САЬЬ
ЗИАР ϋΚΟΡ ; нам просто нужно значение (не оценка) зив
ΒΒΝ МетЬегз111р Ехр1гес1 ; успех ;отладка
РОЗИ @МетЬегзЫр_СНеск_Зиссезз. БеЬид ризн ОЕвис_РК1ЫТ_зузсАьь
САЬЬ ризн зиссЕзз
КЕТ
МетЬегзН1р_Ехр1ге0:
;отладка
РЦЗН @Г4етЬегзЫр_Ехр1гес1. ЬеЬид ризн 0Евис_РК1мт_зузсАьь
САЬЬ
ВВА МеггЗэегзШр^ СИеск РаИес!
МетЬегзЫр_СЬеск_ГаИе6:
;отладка
РиЗН бМепхЬегзШр—СНеск—ЕаНиге. ВеЬид ризн ЬЕвис_РК1МТ_зузсАьь
САЬЬ ризн ?А1ьикЕ
ВЕТ
Е.З 81оЬа1иЪ11з
Е.3.1 1п-Ьиь±1з.азш »*++++++++★+++++++++++++++++★++★+★+++*++++★+++++++*++★+++++ ; Имя файла: ΙηίϋΤίΙε.азт ; Описание: утилиты для сравнения 2 целых чисел • *ЛЛЛ + + + + + + 9(+ + + + + + + + + + +4* + + + + + + 9( + 44 + + + + + ** + + ++ +4+ + 49: + + 4 + + + +
- 146 012918 ; включение ιηοΐυάθ 51:аски11з.15.азт со^е ; тхп г
; вычисляет мимнимум между 2 целыми числами
Г ; вход: ... а Ь
| ; выход: ... | а<Ь?а:Ь |
| 1 пип : | |
| ϋυρ | ; ... а Ь Ь |
| ризн 2 | |
| ά3Κ рюк | ; ... а Ъ Ь а |
| СМР | ; . . . а Ь стр__гези1Ь |
| ΒΚΝ Зиар | Зкаск ; ... а Ь |
| ϋΚΟΡ | |
| КЕТ | ; а |
| Зиар—Збаск: | |
| ЗНАР | |
| ОВОР | |
| ВЕТ | ; Ь |
; тах ; вычисляет максимум между 2 целыми числами <
; вход: ... а Ь ; выход: ... а>Ь?а:Ь
| тах: | |||
| ϋυρ | ; ... а | Ь | ь |
| ризн 2 | |||
| гзв р1ск | ; ... а | Ь | Ь а |
| СИР | ; ... а | ь | стр гезиТб |
ΝΕΟ
В ИМ 5иар_ЗЪаск ϋΒΟΡ
ВЕТ ; а
Е. 3.2 РгхпЪ1пЪ.аят
Г ; Имя файла: Ρηηίΐηΐ: .азт ; Описание: преобразует целое число (знаковое или беззнаковое) в строку г
;; Примечание: необходимо, чтобы ЗбаскШ:11з.азш уже был включен ; выбор данных . даба ; выбор кода . соде ; преобразует целое число в представление строки
- 147 012918 ; параметры: безк, ίη£ ρι-ίηΡΙπΊ::
; дублировать параметр йезс
ЗЯАР
ВОР ризн 2
ЦЗК рхск ; ЗТАСК: ог1дча1, эЕагСэЕггпд, збагДзГгФпд, ипз!дпе^а1 ; теперь у нас есть дополнительная копия целого числа на ; дне, которую мы будем использовать для проверки ; исходного знака ргд-ПСГпРЬоор:
; получить одну цифру ϋϋΡ ризн 10
ΜΟϋ ; преобразовать в азс11
РиЗН 48 ; А8С11 для '0'
Άϋϋ ; получить адрес для выходного буфера
РИЗН 2
73К ргск
РОКЕВ ; печатать в буфер ; перемещение указателя нашего буфера
ЗИАР ризн ι
АРР
ЗИАР ; разделить на 10 и посмотреть, где мы ризн ίο
Ρίν си?
ВНР ргίΓ'ίΙ.ηЕЬоор ϋΗΟΡ ; избавиться от 0 на вершине ; ЗТАСК = ог1дпит, зЬагбоДзбг1пд, епйоЕзДг1пд ; если исходное число отрицательно, поставить знак минус завершить символом конца строки ϋϋ₽ ризн о ЗНАР РОКЕВ ; переместить конец строки на 1 вверх, ; чтобы не перебрасывать символ конца строки риги 1 зив ; готово: нужно просто перевернуть строку £1ίρίοορ:
; получить второй байт оир
РЕЕКВ ; получить первый байт ризн 2
03В ргск
РЕЕКВ ; поставить первый байт на место последнего ризн 2
ДЗК. рхск
РОКЕВ ; поставить последний байт на место первого ризн 2
ОЗР. р!ск
РОКЕВ ; переместить указатель конца на единицу вверх ризн 1
- 148 012918 зив ; переместить указатель начала на единицу вниз
ЗИАР ризн 1
АОО
3ΝΑΡ ; посмотреть, встретились ли указатели ; сначала нужно дублировать значения цир ризн 2
ГЗК ргск зив
ВНР ίΐίρίοορ ; избавиться от некоторых наносов в стеке ϋκορ
ЭКОР ϋκορ
КЕТ
Е.3.3 3БаскиΕΪ13.азш г
; Имя файла: ЗБаскОБИз. азш ; Описание: функции утилит стека, пришедшие из ΕΌΚΤΗ
Г
1%½½½%½%½½½½½½%½%½½½%½½½½½½½½½%½½½½½½½½½½½½½%½½½½½½½½½½½½½%
Г .ίίηάθΐ _зтАСкит1ьз_ .6е£1пе _ЗТАСК_0Т1ЪЗ_ ; код сос1е ; оуег /
; копировать второй элемент стека г
; вход: ... а Ь ; выход: ... а Ь а
Л ονβΓ:
ризн ι
ЗЗР р!ск
КЕТ ; рхск
I ; вход: ... ν3 ν2 νΐ νθ N ; выход: ... ν3 ν2 νΐ νΟ νΝ
Г ρί-ск:
ризн 1
Αϋϋ ризн 4
- 149 012918 миь ризнзр
Αϋϋ
РЕЕК
КЕТ . епсИ£ ; _ЗТАСК_иТ1ЬЗ_
Е.3.4 З-ЬсЗЫЬ.азт ; Стандартная библиотека для ₽1апкбоп . еди ΗΕΑΡ_ΑϋϋΚ, 16 ; выбор дданных ; выбор кода . соде з£г1еп:
ϋΠΡ
Ιοορ:
Ш₽
РЕЕКВ
ΒΚΖ Эоле ризн 1
ΑΩΟ
ВЕСА 1оор допе:
ЗИАР зив
КЕТ .ехрогб з£г1еп
Е.3.5 ЗЕгСтр.азтп ***>**Л****тк*йР***,*5к’тй* + *т1сЛ'(1г'Л,*,*'!к'*''А*'*!||г***!й****'Л'*-т»Ц- + *'*'-#'*7к**>^1к^·* ; Имя файла: ЗЫСгар.азт ; Описание: тесты зсгея на равенство двух строк ι***..*...**....****.*..*********...******......**.****..*.
.1Епде£ _ЗТВ_СМР_ .йе£1пе _5ТН_СМР_ ; включение
1пс1ийе ЗЪаскисИз. азт код . соде
Г ; экгеч
Г ; тест на равенство двух строк ; вход: ... @зкг1 @зкг2 ί выход: ... пез (гез = 0 ί£ зЬгтпдз аге едиа!, -1 о£Ьеги1зе)
Г зЬгед:
- 150 012918 ; получить смещение между 2 строками 43К очес зив
ЗИАР ; ... смещение @з£гХ зЬгечХоор:
; получить текущий символ зЬг1 вир
| ΡΕΕΚΒ | ; ... смещение @з£гХ сЬагХ |
| ; получить | текущий символ з£г2 |
| 45К ονβΓ | ; ... смещение @з£гХ сЬагХ @з£гХ |
| ризн з | |
| ХЗР ргск | ; ... смещение @з£гХ сйаг1 @з£гХ оЕЕзеЕ |
| АОЙ | |
| ΡΕΕΚΒ | ; ... смещение взСг! сЬагХ сНаг2 |
; теперь сравнить два символа
ЦЗК ονθΓ
3ΌΒ ; ... смещение @з£гХ сЪагХ сНаг1-сЪаг2 ; ЕаИ ΐί ЕЬе сЬаг1 != сЬаг2
КОТ
ЕН. зЕгедЕатХиге ; если сНагХ равен 0 (сЬагХ = сЦаг2 == 0), готово ΒΚΖ вЕгедзиссезз ; ... смешение ЙзЕгХ ; увеличить указатель @®Ьг1 и вернуться к началу цикла ризн X
ΑΒϋ
ВКА з£гед1оор з£гедЕа1Хиге:
; ... смещение @з£гХ сНагХ
ВКОР
ΌΚΟΡ ϋΚΟΡ ризн -ι
КЕТ зЕгеявиссезз:
; ... смещение @з£г1
ОНОР
СКОР ризн о
КЕТ .епс11£ ; ЗТН. СМР _
Е. 4 Ех£еп<1ес13Е:аЕизВ1оск РагатеЕегз
Е. 4.1 Тгапз£егХЗЕаЕиз₽хоххтхЕуСИеск5иссее<1е(1. хп*1 <Уа1ие1451В1оск>
<Уа1иеВ1оск (уре=Рагате1ег“>
<Рагате1егВ1оскпате=ОЫ|да£м>п8>
<Уа1иеВ1оск 1уре=¥а1иеЫ5<,’>
<Уа1иеЬ15®1оск>
<Уа1иеВ1оск 1уре=иЕх1еп<1е<1Рагате1ег>
<Рагате1егВ1оск пате=ВипА§сп{О11Ресг Ла§5 1>
<Уа1иеВ!оск 1уре=¥а1иеЬ15(>
- 151 012918 <Уа1иеЬкИ31оск>
<!—ГО объекта управления —>
<ν а1иеВ1оск (уре-1 81 гйц»>мп>:та г11я: εοηίτοί :0023</V а!иеВ 1оск> <!- Имя агента ->
<У акеВ1оск 1уре=8! йп£>8е|81я!еСопТеп10023</Уа1иеВ1оск>
<!-- И экземпляра -->
<ν а1иеВ1оск (уре- '1п1е£ег>240343</Уа1иеВ1оск>
<!— ГО контекста —>
<Уа1иеВ1оск 1уре=|,8(г1п8>Моуе51а(еСоп!еп40023</Уа1иеВ1оск>
<!— дополнительные параметры — >
<Уа1иеВ1оск Гуре=Уа1иеЪЫ>
< Уа1иеЬ151В 1оск>
<Уа1иеВ1оск Гуре=Рагате1ег>
<·— Единственное, что меняется с
Тгап5ГегХ81аГи5Ргох1тпуСЬескРа|1ед.хт1 ->
<РагатекгВ 1оск пате=Ргох1пп»уС11еске<Г'>
<Уа1иеВ1оск 1уре=’’1те2ег>1 <ЛГ а1иеВ 1оск>
</Рагате(егВ 1оск>
</Уа1иеВ1оск>
</Уа1ие1дз(В1оск>
</Уа1иеВ1оск>
</Уа1иеЕ| з(В 1оск>
<7У а!исВ1оск>
</Рагате1егВ кс к>
</Уа1иеВ1оск>
</ν акеИз1В 1оск>
</Уа!иеВ1оск>
</Рагате»егВ 1оск>
</Уа1иеВ1оск>
<Уа1иеВ1оск |уре=Рагате(ег>
<РагатегегВ1оск пате=Са11Ьаск8>
<Уа[иеВ1оск (уре^'УакеЬйО <Уа1иеЫ51Вкск>
<Уа1 иеВ 1оск 1уре= Εχί епскбРа га те(ег >
<Рагате1егВ1оск пате=ОпАееп!Сотрк!кп'’ Да®з=Г'>
<Уа1иеВ1оск 1уре=Уа1иеЬй(>
< Уа1цеЬ1з1В 1оск>
<!— И экземпляра агента —>
<У’а1иеВ1оск 1у ре=δΐπης >240343</Уа1иеВ !оск>
<!- Процедура обратного вызова —>
<Уа1иеВ1оск 1уре=Уа1ие1а5р'>
<Уа1ие1л5(В1оск>
- 152 012918 <!— Сброс ->
<Уа1иеВ 1оск 1уре-1п 1еусг>0</У а1иеВ1оск>
<1— Имя ->
<Уа1иеВ1оск :уре=,,31п11й>Соп*п>1.А8е11(я.8е18(а(еСо111еп<в023.ОпА8еп(Сотр1ейоп^Уа1иеВ1оск>
<1— куки —>
<Уа1иеВ1оск 1уре=|'1п1едег’,>6<Л'а1иеВ1оск>
</Уа1иеЬ151В1оск>
</Уа1иеВ1оск>
</ν а 1пеШгВ 1оск>
<А'а1иеВ1оск>
</Рагате(егВ 1оск>
</Уа1иеВ1оск>
</У а1ие!лз1В 1ос к>
</Уа1иеВ1оск>
</Рагате1егВ1оск>
</Уа1иеВ1оск>
</ν а1иеЬ1$гВ1оск>
Е.4.2 ТгапяГегХЗДаШвРпжтйуСЪескГаПеб.хт!
<Уа1ие1лзГВ1оск>
<Уа1иеВ1оск суре_Рагате1ег’'>
<Рагате1егВ1оск пате=ОЫ|8а11опз>
<Уа1иеВ1оск »уре=Уа1ие1лй’>
<Уа1иеЬ13(В1оск>
<Уа1иеВ1оск1уре=,,Ех(епбедРагате(ег>
<Рагате1егВ1оск пате=ВипА8епЮпРеег Пад5=1>
<Уа1иеВ1оск Туре=Уа1иеЬйР> <Уа1ие1д$Ш1оск>
<!— ГО объекта управления —>
<Уа1иеВ1оск1уре=81пп8,,>игп:1Паг1™!СОп(го1:(Ю23</Уа1иеВ1оск>
<!— имя агента ->
<Уа1иеВ1оск 1уре=,'81ппд'’>8еГ8»лГеСоп1епН)023<''Уа1иеВ1оск>
<!— ΐ<1 экземпляра <У а 1иеВ 1оск 1у ре=I п(е8ег>240343</Уа1 иеВ 1оск>
<!— ГО контекста <Уа1иеВ1оск1уре=81г1П8>Мо¥е8(а(еСоп1еп10в23</Уа1иеВ1оск>
<!-- дополнительные параметры <Уа1иеВ1оск 1уре=”Уа1ие1аз1>
<У аГиеГазСВ 1оск>
<Уа1иеВ1оск гуре=Рагате(сг|'>
<!- Единственое, что изменяется с ТгапяГегХ8шиаРгох1га1(уС11еск8иссеес!.хт1 ->
<Рагате1егВ1оскпате=,'РгоХ1п1куСЬеске<1>
- 153 012918 < Уа1 иеВ 1оск 1у ре- Ιη 1е£ег>0</У а)иеВ1 оск>
</Рагате1егВ 1оск>
</Уа1иеВ1оск>
</Уа1ие14яВ 1оск>
</Уа1иеВ1оск>
</Уа1ие1лк(Вк>ск>
<Л'а1иеВкюк>
</Рагате(егВ 1оск>
</Уа1иеВ1оск>
</Уа1ие1лз:В1оск>
</Уа1иеВ1оск>
</РагатеГегВ1оск>
</Уа1иеВ1оск>
<Уа1иеВ1оск гуре=’'Рагате4ег>
<Рагате(егВ1оск пате=Са11Ьаскз>
<Уа1иеВ1оск 1уре=’'У а1ие1лз1>
<Уа1ие1,18СВ1оск>
<Уа1иеВ1оск 1уре=Ех1епс1е(1Рагате(ег’'>
<Рагате1егВ1оск пате=ОпА£еп(Сотр1еЦоп (1а£з=Г>
<Уа1иеВ1оск :уре= Уа1иеИ5Г>
<Уа1ие1.кгВ!оск>
<!- ΐά экземпляра агента <Уа1иеВ1оск Гуре=”Ктп£”>240343</У а!иеВ1оск>
<!- Процедура обратного вызова ->
<УаГиеВ1<эск 1уреУа1иеЬЫ’>
<Уа1ие1лз1В1оск>
<!- Сброс <Уа1иеВ 1оск 1уре= Ιη к г > 0</Уа1иеВ1оск>
<!- Имя -->
<Уа1иеВ1оск (уре=81Нп§'|>Сотго1.А5еп15.8е48<а1е€оп1еп10023.0пАбеп1Сотр1е11оп</Уа1иеВ1оск>
<!-- кукн <У а !иеВ 1оск 1урс= Ιη к£ег>0</Уа1 иеВ1 оск>
</У а1иеЬ|з1В 1оск>
<Л'а!иеВ1оск>
</Уа1иеЬ151В1оск>
<Л/а1иеВ1оск>
</РагатегегВ1оск>
<Уа1иеВ1оск>
</Уа1ие1л51Вк>ск>
<Л'а1иеВ1оск>
</Рагате1егВ1оск>
- 154 012918 <Уа1иеВ1оск>
</У а1иеЬ1з1В1оск>
Ε. 4.3 Тгапз£егХЗЪаЪизРгох±ш1ЪуСЬескЗиссее<Яе<Я. авт
| 0x00 | 0x00 | 0x00 | 0x02 | ОхОО | ОхОО | ОхОО | 0x04 | ОхОО | ОхОО | ОхОО | 0x20 | |
| 0x00 | 0x00 | 0x00 | ОхОС | 0х4Е | 0x62 | ОхбС | 0x69 | 0x67 | 0x61 | 0x7 4 | 0x69 | ОхбЕ |
| ОхбЕ | 0x73 | 0x00 | 0x00 | ОхОО | ОхОО | 0x07 | ОхОО | ОхОО | ОхОО | ОхОС | ОхОО | ОхОО |
| 0x00 | 0x01 | ОхОО | 0x00 | ОхОО | 0x05 | ОхОО | 0x00 | ОхОО | 0x04 | ОхОО | ОхОО | ОхОО |
| 0x01 | 0x00 | 0x00 | 0x00 | ОхОЕ | 0x52 | 0x75 | ОхбЕ | 0x41 | 0x67 | 0x65 | ОхбЕ | 0x74 |
| 0х4Г | ОхбЕ | 0x50 | 0x65 | 0x65 | 0x72 | ОхОО | ОхОО | ОхОО | ОхОО | 0x07 | ОхОО | ОхОО |
| 0x00 | 0x92 | 0x00 | 0x00 | ОхОО | 0x05 | ОхОО | ОхОО | ОхОО | 0x02 | ОхОО | ОхОО | ОхОО |
| 0x18 | 0x7 5 | 0x7 2 | ОхбЕ | ОхЗА | 0x60 | 0x61 | 0x72 | ОхбС | 0x69 | ОхбЕ | ОхЗА | 0x63 |
| ОхбЕ | ОхбЕ | 0x74 | 0x72 | ОхбЕ | ОхбС | ОхЗА | 0x30 | 0x30 | 0x32 | 0x33 | ОхОО | ОхОО |
| 0x00 | 0x00 | 0x02 | ОхОО | ОхОО | ОхОО | 0x14 | 0x53 | 0x65 | 0x74 | 0x53 | 0x74 | 0x61 |
| 0x74 | 0x65 | 0x4 3 | ОхбЕ | ОхбЕ | 0x7 4 | 0x65 | ОхбЕ | 0x7 4 | 0x30 | 0x30 | 0x32 | 0x33 |
| 0x00 | 0x00 | ОхОО | ОхОО | ОхОО | ОхОО | ОхОО | ОхОО | 0x04 | ОхОО | 0x03 | ОхАА | 0χϋ7 |
| 0x00 | 0x00 | 0x00 | 0x02 | ОхОО | ОхОО | ОхОО | 0x15 | 0χ4ϋ | ОхбЕ | 0x7 6 | 0x65 | 0x53 |
| 0x74 | 0x61 | 0x74 | 0x65 | 0x43 | ОхбЕ | ОхбЕ | 0x74 | 0x65 | ОхбЕ | 0x74 | 0x30 | 0x30 |
| 0x32 | 0x33 | 0x00 | ОхОО | ОхОО | ОхОО | 0x07 | ОхОО | ОхОО | ОхОО | 0x25 | ОхОО | ОхОО |
| 0x00 | 0x01 | 0x00 | ОхОО | ОхОО | 0x04 | ОхОО | ОхОО | ОхОО | 0x10 | ОхОО | ОхОО | ОхОО |
| 0x11 | 0x50 | 0x72 | ОхбЕ | 0x78 | 0x69 | 0x60 | 0x69 | 0x74 | 0x79 | 0x4 3 | 0x68 | 0x65 |
| 0x63 | 0x6В | 0x65 | 0x64 | ОхОО | ОхОО | ОхОО | ОхОО | ОхОО | ОхОО | ОхОО | ОхОО | 0x04 |
| 0x00 | 0x00 | 0x00 | 0x01 | ОхОО | ОхОО | ОхОО | 0x04 | ОхОО | ОхОО | ОхОО | 0х1Е | ОхОО |
| 0x00 | 0x00 | ОхОА | 0x43 | 0x61 | ОхбС | ОхбС | 0x62 | 0x61 | 0x63 | ОхбВ | 0x73 | ОхОО |
| 0x00 | 0x00 | ОхОО | 0x07 | ОхОО | ОхОО | ОхОО | ОхОС | ОхОО | ОхОО | ОхОО | 0x01 | ОхОО |
| 0x00 | 0x00 | 0x05 | ОхОО | ОхОО | ОхОО | 0x04 | ОхОО | ОхОО | ОхОО | 0x01 | ОхОО | ОхОО |
| 0x00 | 0x12 | 0х4Е | ОхбЕ | 0x41 | 0x67 | 0x65 | ОхбЕ | 0x74 | 0x43 | ОхбЕ | 0χ6ϋ | 0x70 |
| ОхбС | 0x65 | 0x74 | 0x69 | ОхбЕ | ОхбЕ | ОхОО | ОхОО | ОхОО | ОхОО | 0x07 | ОхОО | ОхОО |
| 0x00 | ОхбС | ОхОО | ОхОО | ОхОО | 0x02 | ОхОО | 0x00 | ОхОО | 0x02 | ОхОО | ОхОО | ОхОО |
| 0x07 | 0x32 | 0x34 | 0x30 | 0x33 | 0x34 | 0x33 | ОхОО | ОхОО | ОхОО | ОхОО | 0x07 | ОхОО |
| 0x00 | 0x00 | 0x55 | ОхОО | ОхОО | ОхОО | 0x03 | ОхОО | ОхОО | ОхОО | ОхОО | ОхОО | ОхОО |
| 0x00 | 0x04 | ОхОО | ОхОО | ОхОО | ОхОО | ОхОО | ОхОО | ОхОО | 0x02 | ОхОО | ОхОО | ОхОО |
| 0x35 | 0x43 | ОхбЕ | ОхбЕ | 0x74 | 0x72 | ОхбЕ | ОхбС | 0х2Е | 0x41 | 0x67 | 0x65 | ОхбЕ |
| 0x74 | 0x73 | 0х2Е | 0x53 | 0x65 | 0x74 | 0x53 | 0x74 | 0x61 | 0x74 | 0x65 | 0x43 | ОхбЕ |
| ОхбЕ | 0x74 | 0x65 | ОхбЕ | 0x74 | 0x30 | 0x30 | 0x32 | 0x33 | Ох2Е | 0х4Г | ОхбЕ | 0x41 |
| 0x67 | 0x65 | ОхбЕ | 0x74 | 0x4 3 | ОхбЕ | 0x60 | 0x70 | ОхбС | 0x65 | 0x74 | 0x69 | ОхбЕ |
| 0x63 | 0x00 | 0x00 | ОхОО | ОхОО | ОхОО | ОхОО | ОхОО | ОхОО | 0x04 | ОхОО | ОхОО | ОхОО |
| 0x00 | Е.4. 0x00 | 4 Тгапв£егХЗЪаЪивРгсх1т1ЪуСЪеск1Га11ее1. авт 0x00 0x00 0x02 0x00 0x00 0x00 0x04 0x00 0x00 | ОхОО | 0x20 | ||||||||
| 0x00 | 0x00 | 0x00 | ОхОС | 0x4? | 0x62 | ОхбС | 0x69 | 0x67 | 0x61 | 0x74 | 0x69 | ОхбЕ |
| ОхбЕ | 0x73 | 0x00 | ОхОО | ОхОО | ОхОО | 0x07 | ОхОО | ОхОО | ОхОО | ОхОС | ОхОО | ОхОО |
| 0x00 | 0x01 | 0x00 | ОхОО | ОхОО | 0x05 | ОхОО | ОхОО | ОхОО | 0x04 | ОхОО | ОхОО | ОхОО |
- 155 012918
| 0x01 | 0x00 | 0x00 | 0x00 | ОхОГ | 0x52 | 0x75 | ОхбЕ | 0x41 | 0x67 | 0x65 | ОхбЕ | 0x74 |
| 0x4? | ОхбЕ | 0x50 | 0x65 | 0x65 | 0x72 | 0x00 | 0x00 | 0x00 | 0x00 | 0x07 | 0x00 | 0x00 |
| 0x00 | 0x92 | 0x00 | 0x00 | 0x00 | 0x05 | 0x00 | 0x00 | 0x00 | 0x02 | 0x00 | 0x00 | 0x00 |
| 0x18 | 0x75 | 0x72 | ОхбЕ | ОхЗА | 0x60 | 0x61 | 0x72 | ОхбС | 0x69 | ОхбЕ | ОхЗА | 0x63 |
| ОхбЕ | ОхбЕ | 0x74 | 0x72 | ОхбЕ | ОхбС | ОхЗА | 0x30 | 0x30 | 0x32 | 0x33 | 0x00 | 0x00 |
| 0x00 | 0x00 | 0x02 | 0x00 | 0x00 | 0x00 | 0x14 | 0x53 | 0x65 | 0x74 | 0x53 | 0x74 | 0x61 |
| 0x74 | 0x65 | 0x4 3 | 0x6? | ОхбЕ | 0x74 | 0x65 | ОхбЕ | 0x74 | 0x30 | 0x30 | 0x32 | 0x33 |
| 0x00 | 0x00 | 0x00 | 0x00 | 0x00 | 0x00 | 0x00 | 0x00 | 0x04 | 0x00 | 0x03 | ОхАА | 0x07 |
| 0x00 | 0x00 | 0x00 | 0x02 | 0x00 | 0x00 | 0x00 | 0x15 | 0x4 ϋ | 0x6? | 0x7 6 | 0x65 | 0x53 |
| 0x74 | 0x61 | 0x74 | 0x65 | 0x43 | ОхбЕ | ОхбЕ | 0x74 | 0x65 | ОхбЕ | 0x74 | 0x30 | 0x30 |
| 0x32 | 0x33 | 0x00 | 0x00 | 0x00 | 0x00 | 0x07 | 0x00 | 0x00 | 0x00 | 0x2 5 | 0x00 | 0x00 |
| 0x00 | 0x01 | 0x00 | 0x00 | 0x00 | 0x04 | 0x00 | 0x00 | ОхОО | ОхЮ | ОхОО | ОхОО | ОхОО |
| 0x11 | 0x50 | 0x72 | ОхбЕ | 0x78 | 0x69 | 0χ6ϋ | 0x69 | 0x74 | 0x7 9 | 0x43 | 0x68 | 0x65 |
| 0x63 | 0x6В | 0x65 | 0x64 | 0x00 | 0x00 | 0x00 | 0x00 | 0x00 | 0x00 | 0x00 | 0x00 | 0x04 |
| 0x00 | 0x00 | 0x00 | 0x00 | 0x00 | 0x00 | 0x00 | 0x04 | 0x00 | 0x00 | 0x00 | 0х1Е | 0x00 |
| 0x00 | 0x00 | ОхОА | 0x43 | 0x61 | ОхбС | ОхбС | 0x62 | 0x61 | 0x63 | ОхбВ | 0x73 | 0x00 |
| 0x00 | 0x00 | 0x00 | 0x07 | 0x00 | 0x00 | 0x00 | ОхОС | 0x00 | 0x00 | 0x00 | 0x01 | 0x00 |
| 0x00 | 0x00 | 0x05 | 0x00 | 0x00 | 0x00 | 0x04 | 0x00 | 0x00 | 0x00 | 0x01 | 0x00 | 0x00 |
| 0x00 | 0x12 | 0х4Е | ОхбЕ | 0x41 | 0x67 | 0x65 | ОхбЕ | 0x74 | 0x43 | ОхбЕ | 0χ6υ | 0x70 |
| 0x60 | 0x65 | 0x74 | 0x69 | ОхбЕ | ОхбЕ | 0x00 | 0x00 | 0x00 | 0x00 | 0x07 | 0x00 | 0x00 |
| 0x00 | ОхбС | 0x00 | 0x00 | 0x00 | 0x02 | 0x00 | 0x00 | 0x00 | 0x02 | 0x00 | 0x00 | 0x00 |
| 0x07 | 0x32 | 0x34 | 0x30 | 0x33 | 0x34 | 0x33 | 0x00 | 0x00 | ОхОО | 0x00 | 0x07 | 0x00 |
| 0x00 | 0x00 | 0x55 | 0x00 | 0x00 | 0x00 | 0x03 | 0x00 | 0x00 | 0x00 | 0x00 | 0x00 | 0x00 |
| 0x00 | 0x04 | 0x00 | 0x00 | 0x00 | 0x00 | 0x00 | 0x00 | 0x00 | 0x02 | 0x00 | 0x00 | 0x00 |
| 0x35 | 0x43 | ОхбЕ | ОхбЕ | 0x74 | 0x72 | ОхбЕ | ОхбС | 0x2 Е | 0x41 | 0x67 | 0x65 | ОхбЕ |
| 0x74 | 0x73 | 0х2Е | 0x53 | 0x65 | 0x74 | 0x53 | 0x74 | 0x61 | 0x74 | 0x65 | 0x4 3 | ОхбЕ |
| ОхбЕ | 0x74 | 0x65 | ОхбЕ | 0x74 | 0x30 | 0x30 | 0x32 | 0x33 | 0х2Е | 0x4? | ОхбЕ | 0x41 |
| 0x67 | 0x65 | ОхбЕ | 0x74 | 0x43 | ОхбЕ | 0x60 | 0x70 | ОхбС | 0x65 | 0x74 | 0x69 | 0x6? |
| ОхбЕ 0x00 | 0x00 | 0x00 | 0x00 | 0x00 | 0x00 | 0x00 | 0x00 | 0x00 | 0x04 | 0x00 | 0x00 | 0x00 |
Хотя вышеприведенное подробное описание было предоставлено для пояснения изобретения, очевидно, что возможны определенные изменения и модификации в пределах объема прилагаемой формулы изобретения. Заметим, что существует много альтернативных способов реализации описанных здесь процессов и устройств. Соответственно, настоящие варианты осуществления следует рассматривать как иллюстративные и неограничительные, и изобретение не подлежит ограничению рассмотренными здесь деталями, но допускает модификации в рамках объема и эквивалентов прилагаемой формулы изобретения.
Claims (21)
- ФОРМУЛА ИЗОБРЕТЕНИЯ1. Способ авторизации доступа к фрагменту электронного контента на компьютерной системе хоста, при этом способ содержит этапы, на которых принимают запрос от пользователя компьютерной системы хоста для доступа к фрагменту электронного контента, извлекают лицензию, связанную с фрагментом электронного контента, причем лицензия содержит объект управления, объект контроллера, объект протектора и объект ключа контента, извлекают первую программу управления из объекта управления и выполняют первую программу управления с использованием механизма управления цифровыми правами, выполняющегося на компьютерной системе хоста, для определения, можно ли удовлетворить запрос, причем при выполнении программы управления оценивают один или несколько объектов связи, причем каждый объект связи представляет соотношение между двумя сущностями, причем по меньшей мере один из одного или нескольких объектов связи содержит вторую программу управления, и при оценивании одного или нескольких объектов связи выполняют вторую программу управления с использованием механизма управления цифровыми правами для определения, действительна ли связь, причем при выполнении определяют, выполняются ли одно или несколько условий, выраженных программой управления.
- 2. Способ по п.1, в котором объект контроллера способен безопасно связывать объект управления с объектом ключа контента.
- 3. Способ по п.1, в котором объект протектора способен безопасно связывать объект ключа контен- 156 012918 та с фрагментом электронного контента.
- 4. Способ по п.1, в котором по меньшей мере одно из одного или нескольких условий содержит требование, чтобы текущее время было до заранее заданного времени.
- 5. Способ по п.1, в котором по меньшей мере одно из одного или нескольких условий содержит требование, чтобы текущее время было после определенного времени.
- 6. Способ по п.1, в котором по меньшей мере одно из одного или нескольких условий содержит требование, чтобы вторая программа управления предварительно не была выполнена больше заранее заданного числа раз.
- 7. Способ по п.1, в котором по меньшей мере одно из одного или нескольких условий содержит требование, чтобы счетчик, хранящийся в памяти, не превышал заранее заданного значения.
- 8. Способ по п.1, в котором по меньшей мере одно из одного или нескольких условий содержит требование, чтобы заранее заданное событие ранее не происходило.
- 9. Способ по п.1, в котором по меньшей мере одно из одного или нескольких условий содержит требование, чтобы компьютерная система хоста имела одну или несколько заранее заданных характеристик.
- 10. Способ по п.1, в котором по меньшей мере одно из одного или нескольких условий содержит требование, чтобы программное обеспечение, выполняющееся на компьютерной системе хоста для представления фрагмент электронного контента, было неспособно экспортировать фрагмент электронного контента на заранее заданный интерфейс.
- 11. Способ авторизации выполнения данного действия на фрагменте электронного контента, при этом способ содержит этапы, на которых выполняют первую программу управления с использованием виртуальной машины, выполняющейся на первом механизме управления цифровыми правами, причем первая программа управления способна определять, может ли данное действие осуществляться на фрагменте электронного контента, причем первая программа управления способна оценивать первое множество из одного или нескольких условий, которые должны выполняться для того, чтобы осуществление данного действия было авторизовано, причем по меньшей мере одно из первого множества из одного или нескольких условий содержит требование, чтобы один или несколько объектов связи были доступны механизму управления цифровыми правами, причем объекты связи логически связывают первый узел, представляющий первую сущность, со вторым узлом, представляющим вторую сущность, извлекают один или несколько объектов связи, причем каждый из объектов связи выражает соотношение между двумя сущностями, и по меньшей мере один из объектов связи включает в себя вторую программу управления, причем вторая программа управления способна оценивать второе множество из одного или нескольких условий, которые должны выполняться, чтобы по меньшей мере один объект связи можно было считать действительным, и используют механизм управления цифровыми правами для выполнения второй программы управления.
- 12. Способ по п.11, в котором первое множество из одного или нескольких условий включает в себя условие, относящееся к времени.
- 13. Способ по п.11, в котором второе множество из одного или нескольких условий включает в себя условие, относящееся к времени.
- 14. Способ по п.11, в котором по меньшей мере одно из первого множества условий и второго множества условий содержит требование, чтобы счетчик, хранящийся в памяти, не превышал заранее заданного значения.
- 15. Способ авторизации доступа к фрагменту электронного контента в системе управления цифровыми правами, содержащей механизм управления цифровыми правами, включающий в себя виртуальную машину, причем способ содержит этапы, на которых принимают запрос на доступ к фрагменту электронного контента или иное его использование, идентифицируют лицензию, связанную с фрагментом электронного контента, причем лицензия содержит программу управления и ключ контента, выполняют программу управления с использованием виртуальной машины, получают выход виртуальной машины, причем выход указывает, что запрашиваемый доступ или иное использование фрагмента электронного контента авторизован(о), пока выполняется обязательство, определяют, что приложение хоста способно выполнять обязательство, и разрешают запрашиваемый доступ или иное использование фрагмента электронного контента при выполнении обязательства, включающего в себя использование ключа контента для дешифрования фрагмента электронного контента.
- 16. Способ по п.15, в котором обязательство содержит представление фрагмента электронного контента в формате пониженного качества.
- 17. Способ по п.15, в котором обязательство содержит запись информации аудита, относящейся к доступу или иному использованию фрагмента электронного контента, и передачу информации аудита в удаленное место.- 157 012918
- 18. Способ по п.15, в котором обязательство содержит требование, чтобы указанные функции среды хоста, в которой выполняется система управления цифровыми правами, были отключены.
- 19. Способ по п.18, в котором фрагмент электронного контента включает в себя рекламу и в котором указанные функции включают в себя возможность перемотки вперед и назад в ходе представления фрагмента электронного контента.
- 20. Способ по п.18, в котором указанные функции включают в себя возможность экспорта фрагмента электронного контента в определенную технологию.
- 21. Способ авторизации доступа к фрагменту электронного контента в системе хоста, содержащей механизм управления цифровыми правами, включающий в себя виртуальную машину, при этом способ содержит этапы, на которых принимают запрос на доступ к фрагменту электронного контента или иное его использование, идентифицируют лицензию, связанную с фрагментом электронного контента, причем лицензия содержит программу управления и ключ контента, выполняют программу управления с использованием виртуальной машины, определяют, что запрашиваемый доступ или иное использование фрагмента электронного контента можно авторизовать, пока выполняется обязательство, определяют, что система хоста не способна выполнять обязательство, и отказывают в запрашиваемом доступе или ином использовании фрагмента электронного контента.
Applications Claiming Priority (8)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US72808905P | 2005-10-18 | 2005-10-18 | |
| US77202406P | 2006-02-09 | 2006-02-09 | |
| US79117906P | 2006-04-10 | 2006-04-10 | |
| US74457406P | 2006-04-10 | 2006-04-10 | |
| US79892506P | 2006-05-08 | 2006-05-08 | |
| US74671206P | 2006-05-08 | 2006-05-08 | |
| US83506106P | 2006-08-01 | 2006-08-01 | |
| PCT/US2006/040898 WO2007047846A2 (en) | 2005-10-18 | 2006-10-18 | Methods for digital rights management |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| EA200801117A1 EA200801117A1 (ru) | 2009-02-27 |
| EA012918B1 true EA012918B1 (ru) | 2010-02-26 |
Family
ID=37890788
Family Applications (2)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| EA200901153A EA200901153A1 (ru) | 2005-10-18 | 2006-10-18 | Системы и способы на основе механизма управления цифровыми правами |
| EA200801117A EA012918B1 (ru) | 2005-10-18 | 2006-10-18 | Системы и способы на основе механизма управления цифровыми правами |
Family Applications Before (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| EA200901153A EA200901153A1 (ru) | 2005-10-18 | 2006-10-18 | Системы и способы на основе механизма управления цифровыми правами |
Country Status (12)
| Country | Link |
|---|---|
| US (5) | US20070172041A1 (ru) |
| EP (4) | EP2090998B1 (ru) |
| JP (2) | JP2009512096A (ru) |
| KR (3) | KR101285024B1 (ru) |
| CN (2) | CN102073819B (ru) |
| AP (1) | AP2008004453A0 (ru) |
| AU (1) | AU2006304655B2 (ru) |
| BR (1) | BRPI0617490A2 (ru) |
| CA (1) | CA2626244A1 (ru) |
| EA (2) | EA200901153A1 (ru) |
| IL (1) | IL190957A (ru) |
| WO (1) | WO2007047846A2 (ru) |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| RU2601146C2 (ru) * | 2011-08-10 | 2016-10-27 | Квэлкомм Инкорпорейтед | Основанная на уровне ослабления ассоциация в сетях связи |
| RU2722239C1 (ru) * | 2019-11-26 | 2020-05-28 | Общество с ограниченной ответственностью «ПИРФ» (ООО «ПИРФ») | Способ создания и использования формата исполняемого файла с динамическим расширяемым заголовком |
Families Citing this family (348)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20020019814A1 (en) * | 2001-03-01 | 2002-02-14 | Krishnamurthy Ganesan | Specifying rights in a digital rights license according to events |
| US7155012B2 (en) * | 2002-01-02 | 2006-12-26 | Sony Corporation | Slice mask and moat pattern partial encryption |
| WO2003061288A1 (en) | 2002-01-02 | 2003-07-24 | Sony Electronics Inc. | Partial encryption and pid mapping |
| US8051443B2 (en) * | 2002-01-02 | 2011-11-01 | Sony Corporation | Content replacement by PID mapping |
| US7376233B2 (en) | 2002-01-02 | 2008-05-20 | Sony Corporation | Video slice and active region based multiple partial encryption |
| US8818896B2 (en) | 2002-09-09 | 2014-08-26 | Sony Corporation | Selective encryption with coverage encryption |
| US7292692B2 (en) * | 2003-03-25 | 2007-11-06 | Sony Corporation | Content scrambling with minimal impact on legacy devices |
| US7286667B1 (en) | 2003-09-15 | 2007-10-23 | Sony Corporation | Decryption system |
| US7496500B2 (en) * | 2004-03-01 | 2009-02-24 | Microsoft Corporation | Systems and methods that determine intent of data and respond to the data based on the intent |
| US20050204900A1 (en) * | 2004-03-17 | 2005-09-22 | Easynotes, Llc | Note collection utility |
| JP2006085483A (ja) * | 2004-09-16 | 2006-03-30 | Sony Corp | ライセンス処理装置，プログラムおよびライセンス貸出方法 |
| US7979706B1 (en) * | 2004-09-29 | 2011-07-12 | Rockwell Automation Technologies, Inc. | Systems and methods for queuing an action in industrial automation systems |
| US20100071070A1 (en) * | 2005-01-07 | 2010-03-18 | Amandeep Jawa | Managing Sharing of Media Content From a Server Computer to One or More of a Plurality of Client Computers Across the Computer Network |
| US8666900B1 (en) * | 2005-03-30 | 2014-03-04 | Intuit Inc. | Secure product enablement over channels with narrow bandwidth |
| US9418040B2 (en) | 2005-07-07 | 2016-08-16 | Sciencelogic, Inc. | Dynamically deployable self configuring distributed network management system |
| US20070094366A1 (en) * | 2005-10-20 | 2007-04-26 | Ayoub Ramy P | System and method for real-time processing and distribution of media content in a network of media devices |
| US20070094276A1 (en) * | 2005-10-20 | 2007-04-26 | Isaac Emad S | Method for obtaining and managing restricted media content in a network of media devices |
| US7921165B2 (en) * | 2005-11-30 | 2011-04-05 | Microsoft Corporation | Retaining mail for availability after relay |
| US8015200B2 (en) * | 2005-12-24 | 2011-09-06 | Phil Seiflein | Multimedia platform synchronizer |
| US7734754B2 (en) * | 2005-12-28 | 2010-06-08 | Microsoft Corporation | Reviewing effectiveness of communication rules system |
| WO2007120360A2 (en) * | 2005-12-29 | 2007-10-25 | Blue Jungle | Information management system |
| KR100834752B1 (ko) * | 2006-02-17 | 2008-06-05 | 삼성전자주식회사 | 컨텐츠의 라이센스를 전달하기 위한 장치 및 방법 |
| US7555464B2 (en) * | 2006-03-01 | 2009-06-30 | Sony Corporation | Multiple DRM management |
| US8429300B2 (en) | 2006-03-06 | 2013-04-23 | Lg Electronics Inc. | Data transferring method |
| US20090133129A1 (en) | 2006-03-06 | 2009-05-21 | Lg Electronics Inc. | Data transferring method |
| CA2636002C (en) | 2006-03-06 | 2016-08-16 | Lg Electronics Inc. | Data transfer controlling method, content transfer controlling method, content processing information acquisition method and content transfer system |
| US8744885B2 (en) * | 2006-03-28 | 2014-06-03 | Snowflake Itm, Inc. | Task based organizational management system and method |
| US7992175B2 (en) | 2006-05-15 | 2011-08-02 | The Directv Group, Inc. | Methods and apparatus to provide content on demand in content broadcast systems |
| US8001565B2 (en) | 2006-05-15 | 2011-08-16 | The Directv Group, Inc. | Methods and apparatus to conditionally authorize content delivery at receivers in pay delivery systems |
| US8095466B2 (en) | 2006-05-15 | 2012-01-10 | The Directv Group, Inc. | Methods and apparatus to conditionally authorize content delivery at content servers in pay delivery systems |
| US8775319B2 (en) | 2006-05-15 | 2014-07-08 | The Directv Group, Inc. | Secure content transfer systems and methods to operate the same |
| US8996421B2 (en) | 2006-05-15 | 2015-03-31 | The Directv Group, Inc. | Methods and apparatus to conditionally authorize content delivery at broadcast headends in pay delivery systems |
| FR2901651B1 (fr) * | 2006-05-24 | 2012-01-20 | Noel Pampagnin | Diffusion de documents electroniques preservant les droits d'auteur et autorisant la copie privee |
| US8549295B2 (en) | 2006-05-31 | 2013-10-01 | Microsoft Corporation | Establishing secure, mutually authenticated communication credentials |
| US8726020B2 (en) * | 2006-05-31 | 2014-05-13 | Microsoft Corporation | Updating configuration information to a perimeter network |
| US8028026B2 (en) * | 2006-05-31 | 2011-09-27 | Microsoft Corporation | Perimeter message filtering with extracted user-specific preferences |
| US20080028218A1 (en) * | 2006-06-13 | 2008-01-31 | Simon Jonathon B | Software & license and physical/virtual machine asset management library application with check-out/check-in, front-end asset load, tracking, reporting, reconciliation and associated methods |
| US20080010091A1 (en) * | 2006-07-10 | 2008-01-10 | Kim Seungyeon | Method and System for Sharing a User-Medical-Record |
| US8166113B2 (en) * | 2006-08-02 | 2012-04-24 | Microsoft Corporation | Access limited EMM distribution lists |
| KR101369749B1 (ko) * | 2006-09-04 | 2014-03-06 | 삼성전자주식회사 | Ｄｒｍ 카드를 이용한 콘텐츠 해독 방법 |
| KR20080022476A (ko) * | 2006-09-06 | 2008-03-11 | 엘지전자 주식회사 | 논컴플라이언트 컨텐츠 처리 방법 및 디알엠 상호 호환시스템 |
| JP2008065696A (ja) * | 2006-09-08 | 2008-03-21 | Toshiba Corp | コンテンツ共有システム及びコンテンツ共有方法 |
| US8612847B2 (en) * | 2006-10-03 | 2013-12-17 | Adobe Systems Incorporated | Embedding rendering interface |
| US7886226B1 (en) | 2006-10-03 | 2011-02-08 | Adobe Systems Incorporated | Content based Ad display control |
| US20100098248A1 (en) * | 2006-10-31 | 2010-04-22 | Agency For Science Technology And Research | Device and method of generating and distributing access permission to digital object |
| US8533846B2 (en) * | 2006-11-08 | 2013-09-10 | Citrix Systems, Inc. | Method and system for dynamically associating access rights with a resource |
| KR101145848B1 (ko) * | 2006-11-29 | 2012-05-17 | 삼성전자주식회사 | 콘텐츠 전송을 위한 접근 제어 방법 및 상기 접근 제어방법을 이용하는 네트워크의 노드 |
| EP2126806A4 (en) * | 2006-12-06 | 2011-01-19 | Marion Darnell Jones | SYSTEM FOR FACIAL OWNERSHIP OF INTELLECTUAL PROPERTY |
| US20080140826A1 (en) * | 2006-12-08 | 2008-06-12 | Microsoft Corporation | Monitoring and controlling electronic message distribution |
| US8312558B2 (en) | 2007-01-03 | 2012-11-13 | At&T Intellectual Property I, L.P. | System and method of managing protected video content |
| US8918508B2 (en) | 2007-01-05 | 2014-12-23 | Lg Electronics Inc. | Method for transferring resource and method for providing information |
| WO2008088856A1 (en) | 2007-01-17 | 2008-07-24 | Intertrust Technologies Corporation | Methods, systems, and apparatus for fragmented file sharing |
| US20080178198A1 (en) * | 2007-01-22 | 2008-07-24 | Media Ripple, Llc | Distributed digital media management |
| WO2008100120A1 (en) | 2007-02-16 | 2008-08-21 | Lg Electronics Inc. | Method for managing domain using multi domain manager and domain system |
| KR20080081631A (ko) * | 2007-03-06 | 2008-09-10 | 주식회사 팬택 | 이동 단말에 탑재되는 디지털 권한 관리 장치 및 이를이용한 디지털 권한 관리 방법 |
| US20080226078A1 (en) * | 2007-03-12 | 2008-09-18 | Microsoft Corporation | Enabling recording and copying data |
| US8966252B2 (en) * | 2007-03-13 | 2015-02-24 | Board Of Trustees Of Michigan State University | Private entity authentication for pervasive computing environments |
| WO2008130191A1 (en) * | 2007-04-23 | 2008-10-30 | Lg Electronics Inc. | Method for using contents, method for sharing contents and device based on security level |
| WO2008136639A1 (en) * | 2007-05-07 | 2008-11-13 | Lg Electronics Inc. | Method and system for secure communication |
| US8627409B2 (en) * | 2007-05-15 | 2014-01-07 | Oracle International Corporation | Framework for automated dissemination of security metadata for distributed trust establishment |
| US8539233B2 (en) * | 2007-05-24 | 2013-09-17 | Microsoft Corporation | Binding content licenses to portable storage devices |
| US8073828B2 (en) * | 2007-06-14 | 2011-12-06 | Curbis Corporation | Licensed rights clearance and tracking for digital assets |
| US20080313085A1 (en) * | 2007-06-14 | 2008-12-18 | Motorola, Inc. | System and method to share a guest version of rights between devices |
| US8661552B2 (en) * | 2007-06-28 | 2014-02-25 | Microsoft Corporation | Provisioning a computing system for digital rights management |
| US8646096B2 (en) * | 2007-06-28 | 2014-02-04 | Microsoft Corporation | Secure time source operations for digital rights management |
| US8689010B2 (en) * | 2007-06-28 | 2014-04-01 | Microsoft Corporation | Secure storage for digital rights management |
| KR101200572B1 (ko) * | 2007-07-09 | 2012-11-13 | 삼성전자주식회사 | 공개 브로드캐스트 암호화를 이용한 인증 방법 및 컨텐츠재생 방법과 그 장치 |
| JP5351158B2 (ja) * | 2007-07-23 | 2013-11-27 | インタートラスト テクノロジーズ コーポレイション | テザード装置システム及び方法 |
| CN101809580B (zh) * | 2007-07-23 | 2014-01-08 | 英特托拉斯技术公司 | 动态媒体分区系统和方法 |
| WO2009019895A1 (ja) * | 2007-08-09 | 2009-02-12 | Panasonic Corporation | 端末装置、サーバ及びそのシステム |
| JP4946726B2 (ja) * | 2007-08-22 | 2012-06-06 | 富士ゼロックス株式会社 | 文書操作システムおよび管理装置およびプログラム |
| US20090083544A1 (en) * | 2007-08-23 | 2009-03-26 | Andrew Scholnick | Security process for private data storage and sharing |
| EP2034661A1 (en) * | 2007-09-07 | 2009-03-11 | Deutsche Telekom AG | Method and system for distributed, localized authentication in the framework of 802.11 |
| US8819815B1 (en) | 2007-10-16 | 2014-08-26 | Jpmorgan Chase Bank, N.A. | Method and system for distributing and tracking information |
| CN101436930A (zh) * | 2007-11-16 | 2009-05-20 | 华为技术有限公司 | 一种密钥分发的方法、系统和设备 |
| KR100988374B1 (ko) * | 2007-12-14 | 2010-10-18 | 엘지전자 주식회사 | 사용권리 이동 방법, 사용권리의 발급권한 관리 방법 및시스템 |
| US9984369B2 (en) * | 2007-12-19 | 2018-05-29 | At&T Intellectual Property I, L.P. | Systems and methods to identify target video content |
| US9773098B1 (en) * | 2007-12-19 | 2017-09-26 | Google Inc. | Media content feed format for management of content in a content hosting website |
| US9143493B2 (en) | 2007-12-20 | 2015-09-22 | The Directv Group, Inc. | Method and apparatus for communicating between a user device and a gateway device to form a system to allow a partner service to be provided to the user device |
| US20090162032A1 (en) * | 2007-12-21 | 2009-06-25 | Aceurity, Inc. | Smart Viewing Rights System and Switch |
| US8286236B2 (en) * | 2007-12-21 | 2012-10-09 | The Invention Science Fund I, Llc | Manufacturing control system |
| US9626487B2 (en) * | 2007-12-21 | 2017-04-18 | Invention Science Fund I, Llc | Security-activated production device |
| US9071436B2 (en) * | 2007-12-21 | 2015-06-30 | The Invention Science Fund I, Llc | Security-activated robotic system |
| US9128476B2 (en) * | 2007-12-21 | 2015-09-08 | The Invention Science Fund I, Llc | Secure robotic operational system |
| US20110178619A1 (en) * | 2007-12-21 | 2011-07-21 | Searete Llc, A Limited Liability Corporation Of The State Of Delaware | Security-activated robotic tasks |
| US8752166B2 (en) * | 2007-12-21 | 2014-06-10 | The Invention Science Fund I, Llc | Security-activated operational components |
| US8429754B2 (en) * | 2007-12-21 | 2013-04-23 | The Invention Science Fund I, Llc | Control technique for object production rights |
| US9818071B2 (en) * | 2007-12-21 | 2017-11-14 | Invention Science Fund I, Llc | Authorization rights for operational components |
| US20090164379A1 (en) * | 2007-12-21 | 2009-06-25 | Searete Llc, A Limited Liability Corporation Of The State Of Delaware | Conditional authorization for security-activated device |
| US10049190B1 (en) * | 2007-12-21 | 2018-08-14 | Symantec Corporation | Method and apparatus for remotely managing a resource at a computer |
| US20090172420A1 (en) * | 2007-12-31 | 2009-07-02 | Kabushiki Kaisha Toshiba | Tamper resistant method and apparatus for a storage device |
| US20090204967A1 (en) * | 2008-02-08 | 2009-08-13 | Unisys Corporation | Reporting of information pertaining to queuing of requests |
| CA2707246C (en) | 2009-07-07 | 2015-12-29 | Certusview Technologies, Llc | Automatic assessment of a productivity and/or a competence of a locate technician with respect to a locate and marking operation |
| US8532342B2 (en) * | 2008-02-12 | 2013-09-10 | Certusview Technologies, Llc | Electronic manifest of underground facility locate marks |
| US8270666B2 (en) * | 2008-02-12 | 2012-09-18 | Certusview Technologies, Llc | Searchable electronic records of underground facility locate marking operations |
| US8672225B2 (en) | 2012-01-31 | 2014-03-18 | Ncr Corporation | Convertible barcode reader |
| US8165304B2 (en) * | 2008-02-18 | 2012-04-24 | Sungkyunkwan University Foundation For Corporate Collaboration | Domain digital rights management system, license sharing method for domain digital rights management system, and license server |
| US8462954B2 (en) * | 2008-05-30 | 2013-06-11 | Motorola Mobility Llc | Content encryption using at least one content pre-key |
| EP2291784B1 (en) * | 2008-06-04 | 2019-12-04 | Koninklijke Philips N.V. | Method and a system of healthcare data handling |
| US20090326964A1 (en) * | 2008-06-25 | 2009-12-31 | Microsoft Corporation | Extensible agent-based license structure |
| US8280631B2 (en) | 2008-10-02 | 2012-10-02 | Certusview Technologies, Llc | Methods and apparatus for generating an electronic record of a marking operation based on marking device actuations |
| US8595484B2 (en) * | 2008-07-29 | 2013-11-26 | Motorola Solutions, Inc. | Method and device for distributing public key infrastructure (PKI) certificate path data |
| US8655826B1 (en) | 2008-08-01 | 2014-02-18 | Motion Picture Laboratories, Inc. | Processing and acting on rules for content recognition systems |
| US8458128B2 (en) * | 2008-08-26 | 2013-06-04 | Microsoft Corporation | Minimal extensions required for multi-master offline and collaboration for devices and web services |
| GB0815651D0 (en) * | 2008-08-28 | 2008-10-08 | Omnifone Ltd | Content ingestion |
| CA2677504A1 (en) * | 2008-09-03 | 2010-03-03 | Dundas Data Visualization, Inc. | Systems and methods for providing security for software applications |
| US9076484B2 (en) | 2008-09-03 | 2015-07-07 | Sandisk Technologies Inc. | Methods for estimating playback time and handling a cumulative playback time permission |
| US20100064378A1 (en) * | 2008-09-05 | 2010-03-11 | Samsung Electronics Co., Ltd. | Method and apparatus for managing digital rights management module |
| US10453003B2 (en) * | 2008-09-18 | 2019-10-22 | Microsoft Technology Licensing, Llc | Digital rights management license identification |
| JP5141494B2 (ja) * | 2008-10-27 | 2013-02-13 | ブラザー工業株式会社 | コンテンツ分散保存システム、特殊コンテンツ取得方法、ノード装置、及びノード処理プログラム |
| KR101310218B1 (ko) * | 2008-10-28 | 2013-09-24 | 삼성전자주식회사 | 화상형성장치의 파일 통합 설치 방법 및 파일 통합 설치가 가능한 화상형성장치 |
| US9235572B2 (en) * | 2008-10-31 | 2016-01-12 | Disney Enterprises, Inc. | System and method for updating digital media content |
| US8315994B2 (en) | 2008-10-31 | 2012-11-20 | Disney Enterprises, Inc. | System and method for updating digital media content |
| CN101420430B (zh) * | 2008-11-28 | 2011-12-07 | 华为终端有限公司 | 一种信息安全保护的方法和设备 |
| US9548859B2 (en) * | 2008-12-03 | 2017-01-17 | Google Technology Holdings LLC | Ticket-based implementation of content leasing |
| JP4631969B2 (ja) * | 2008-12-25 | 2011-02-16 | 富士ゼロックス株式会社 | ライセンス管理装置及びライセンス管理プログラム |
| KR101224717B1 (ko) * | 2008-12-26 | 2013-01-21 | 에스케이플래닛 주식회사 | 소프트웨어 라이센스 보호 방법과 그를 위한 시스템, 서버,단말기 및 컴퓨터로 읽을 수 있는 기록매체 |
| US8146159B2 (en) * | 2009-01-20 | 2012-03-27 | Check Point Software Technologies, Ltd. | Methods for inspecting security certificates by network security devices to detect and prevent the use of invalid certificates |
| CA2690239A1 (en) * | 2009-02-10 | 2010-04-12 | Certusview Technologies, Llc | Methods, apparatus, and systems for exchanging information between excavators and other entities associated with underground facility locate and marking operations |
| US8572193B2 (en) | 2009-02-10 | 2013-10-29 | Certusview Technologies, Llc | Methods, apparatus, and systems for providing an enhanced positive response in underground facility locate and marking operations |
| US8902251B2 (en) * | 2009-02-10 | 2014-12-02 | Certusview Technologies, Llc | Methods, apparatus and systems for generating limited access files for searchable electronic records of underground facility locate and/or marking operations |
| CA2897462A1 (en) * | 2009-02-11 | 2010-05-04 | Certusview Technologies, Llc | Management system, and associated methods and apparatus, for providing automatic assessment of a locate operation |
| US8356255B2 (en) * | 2009-02-11 | 2013-01-15 | Certusview Technologies, Llc | Virtual white lines (VWL) for delimiting planned excavation sites of staged excavation projects |
| US20100211591A1 (en) * | 2009-02-16 | 2010-08-19 | Chuan-Hua Chang | Apparatus for processing strings simultaneously |
| US8391494B1 (en) * | 2009-02-26 | 2013-03-05 | Symantec Corporation | Systems and methods for protecting enterprise rights management keys |
| US9282337B2 (en) * | 2009-02-27 | 2016-03-08 | Vixs Systems, Inc. | Media source device with digital format conversion and methods for use therewith |
| US20100241855A1 (en) * | 2009-03-17 | 2010-09-23 | Cyberlink Corp. | Systems and Methods for Secure Execution of Code Using a Hardware Protection Module |
| US8929303B2 (en) * | 2009-04-06 | 2015-01-06 | Samsung Electronics Co., Ltd. | Control and data channels for advanced relay operation |
| GB0906004D0 (en) * | 2009-04-07 | 2009-05-20 | Omnifone Ltd | MusicStation desktop |
| WO2010134996A2 (en) | 2009-05-20 | 2010-11-25 | Intertrust Technologies Corporation | Content sharing systems and methods |
| CN102460496B (zh) | 2009-05-21 | 2016-05-25 | 英特托拉斯技术公司 | 内容递送系统和方法 |
| 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 |
| US8332536B2 (en) * | 2009-06-11 | 2012-12-11 | International Business Machines Corporation | Content protection continuity through authorized chains of components |
| CN101587523B (zh) * | 2009-07-02 | 2012-04-18 | 飞天诚信科技股份有限公司 | 保护软件的方法和装置 |
| US20140289184A1 (en) * | 2009-09-09 | 2014-09-25 | Sanjeev Kumar Biswas | License structure representation for license management |
| US9003553B2 (en) | 2009-09-10 | 2015-04-07 | Symantec Corporation | Viewing content under enterprise digital rights management without a client side access component |
| WO2011071872A1 (en) | 2009-12-07 | 2011-06-16 | Certusview Technologies, Llc | Methods, apparatus, and systems for facilitating compliance with marking specifications for dispensing marking material |
| TW201122898A (en) * | 2009-12-18 | 2011-07-01 | Hannstar Display Corp | Digital data management system and method. |
| US9589114B2 (en) * | 2010-01-05 | 2017-03-07 | Microsoft Technology Licensing, Llc | Policy for digital rights management |
| US8712045B2 (en) * | 2010-01-07 | 2014-04-29 | Microsoft Corporation | Digital rights management for media streams |
| US10305910B2 (en) | 2010-01-15 | 2019-05-28 | Apple Inc. | Accessing specialized fileserver |
| US10268805B2 (en) * | 2010-01-26 | 2019-04-23 | At&T Intellectual Property I, L.P. | System and method for providing multimedia digital rights transfer |
| US8683370B2 (en) | 2010-03-01 | 2014-03-25 | Dundas Data Visualization, Inc. | Systems and methods for generating data visualization dashboards |
| US8612313B2 (en) * | 2010-03-03 | 2013-12-17 | Verizon Patent And Licensing Inc. | Metadata subscription systems and methods |
| US8544103B2 (en) | 2010-05-04 | 2013-09-24 | Intertrust Technologies Corporation | Policy determined accuracy of transmitted information |
| GB201008368D0 (en) | 2010-05-20 | 2010-07-07 | Moore Jesse K | Mobile meter |
| US9172680B2 (en) | 2010-06-07 | 2015-10-27 | Protected Mobility, Llc | Systems and methods for enabling secure messaging, command, and control of remote devices, communicated via a short message service or other message oriented communications mediums |
| US8984271B2 (en) | 2010-06-07 | 2015-03-17 | Protected Mobility, Llc | User interface systems and methods for input and display of secure and insecure message oriented communications |
| US9143324B2 (en) * | 2010-06-07 | 2015-09-22 | Protected Mobility, Llc | Secure messaging |
| US9602277B2 (en) | 2010-06-07 | 2017-03-21 | Protected Mobilty, Llc | User interface systems and methods for secure message oriented communications |
| US9100693B2 (en) * | 2010-06-08 | 2015-08-04 | Intel Corporation | Methods and apparatuses for securing playback content |
| US8874896B2 (en) | 2010-06-18 | 2014-10-28 | Intertrust Technologies Corporation | Secure processing systems and methods |
| US8799177B1 (en) * | 2010-07-29 | 2014-08-05 | Intuit Inc. | Method and apparatus for building small business graph from electronic business data |
| US8918898B2 (en) | 2010-07-30 | 2014-12-23 | Certusview Technologies, Llc | Methods, apparatus and systems for onsite linking to location-specific electronic records of locate operations |
| WO2012033602A1 (en) | 2010-08-11 | 2012-03-15 | Steven Nielsen | Methods, apparatus and systems for facilitating generation and assessment of engineering plans |
| US8564621B2 (en) * | 2010-08-11 | 2013-10-22 | International Business Machines Corporation | Replicating changes between corresponding objects |
| US20120042134A1 (en) * | 2010-08-11 | 2012-02-16 | Hank Risan | Method and system for circumventing usage protection applicable to electronic media |
| US8392452B2 (en) * | 2010-09-03 | 2013-03-05 | Hulu Llc | Method and apparatus for callback supplementation of media program metadata |
| US8832855B1 (en) * | 2010-09-07 | 2014-09-09 | Symantec Corporation | System for the distribution and deployment of applications with provisions for security and policy conformance |
| US8453258B2 (en) * | 2010-09-15 | 2013-05-28 | Bank Of America Corporation | Protecting an electronic document by embedding an executable script |
| US20120089902A1 (en) | 2010-10-07 | 2012-04-12 | Dundas Data Visualization, Inc. | Systems and methods for dashboard image generation |
| CN103229187B (zh) | 2010-10-15 | 2016-03-23 | 甲骨文美国公司 | Java存储电视机 |
| FR2966620B1 (fr) * | 2010-10-26 | 2012-12-28 | Oberthur Technologies | Procede et systeme de controle de l'execution d'une fonction protegee par authentification d'un utilisateur, notamment pour l'acces a une ressource |
| US8924706B2 (en) | 2010-11-05 | 2014-12-30 | Protected Mobility, Llc | Systems and methods using one time pads during the exchange of cryptographic material |
| US8798262B1 (en) * | 2010-12-23 | 2014-08-05 | Emc Corporation | Preserving LBA information between layers of a storage I/O stack for LBA-dependent encryption |
| CN102098293B (zh) * | 2010-12-28 | 2013-07-10 | 北京深思洛克软件技术股份有限公司 | 加密邮件的预览方法 |
| 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 |
| US8687807B2 (en) | 2011-01-26 | 2014-04-01 | Nagrastar, L.L.C. | Cascading dynamic crypto periods |
| US8458459B2 (en) * | 2011-02-14 | 2013-06-04 | Morega Systems Inc. | Client device and local station with digital rights management and methods for use therewith |
| US20120216269A1 (en) * | 2011-02-18 | 2012-08-23 | Mitel Networks Corporation | Software licensing in a virtualization environment |
| US9519717B2 (en) * | 2011-03-02 | 2016-12-13 | Microsoft Technology Licensing, Llc | Content customization with security for client preferences |
| EP2695101B1 (en) * | 2011-04-04 | 2022-11-09 | Nextlabs, Inc. | Protecting information using policies and encryption |
| US20120284802A1 (en) * | 2011-05-02 | 2012-11-08 | Authentec, Inc. | Method for playing digital contents protected with a drm (digital right management) scheme and corresponding system |
| 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 |
| US9721071B2 (en) * | 2011-06-29 | 2017-08-01 | Sonic Ip, Inc. | Binding of cryptographic content using unique device characteristics with server heuristics |
| US8943313B2 (en) | 2011-07-19 | 2015-01-27 | Elwha Llc | Fine-grained security in federated data sets |
| US9575903B2 (en) * | 2011-08-04 | 2017-02-21 | Elwha Llc | Security perimeter |
| US9298918B2 (en) | 2011-11-30 | 2016-03-29 | Elwha Llc | Taint injection and tracking |
| US9098608B2 (en) | 2011-10-28 | 2015-08-04 | Elwha Llc | Processor configured to allocate resources using an entitlement vector |
| US9460290B2 (en) | 2011-07-19 | 2016-10-04 | Elwha Llc | Conditional security response using taint vector monitoring |
| US9471373B2 (en) | 2011-09-24 | 2016-10-18 | Elwha Llc | Entitlement vector for library usage in managing resource allocation and scheduling based on usage and priority |
| US9465657B2 (en) | 2011-07-19 | 2016-10-11 | Elwha Llc | Entitlement vector for library usage in managing resource allocation and scheduling based on usage and priority |
| US8955111B2 (en) | 2011-09-24 | 2015-02-10 | Elwha Llc | Instruction set adapted for security risk monitoring |
| US9443085B2 (en) | 2011-07-19 | 2016-09-13 | Elwha Llc | Intrusion detection using taint accumulation |
| US9798873B2 (en) | 2011-08-04 | 2017-10-24 | Elwha Llc | Processor operable to ensure code integrity |
| US9558034B2 (en) | 2011-07-19 | 2017-01-31 | Elwha Llc | Entitlement vector for managing resource allocation |
| US9170843B2 (en) | 2011-09-24 | 2015-10-27 | Elwha Llc | Data handling apparatus adapted for scheduling operations according to resource allocation based on entitlement |
| US8800058B2 (en) * | 2011-07-27 | 2014-08-05 | Microsoft Corporation | Licensing verification for application use |
| EP2560124A1 (en) * | 2011-08-02 | 2013-02-20 | Tata Consultancy Services Limited | Access rights management in enterprise digital rights management systems |
| US9270471B2 (en) * | 2011-08-10 | 2016-02-23 | Microsoft Technology Licensing, Llc | Client-client-server authentication |
| US9069943B2 (en) * | 2011-08-15 | 2015-06-30 | Bank Of America Corporation | Method and apparatus for token-based tamper detection |
| US9009855B2 (en) * | 2011-09-11 | 2015-04-14 | Microsoft Technology Licensing, Llc | Generating developer license to execute developer application |
| US9143529B2 (en) | 2011-10-11 | 2015-09-22 | Citrix Systems, Inc. | Modifying pre-existing mobile applications to implement enterprise security policies |
| US9280377B2 (en) | 2013-03-29 | 2016-03-08 | Citrix Systems, Inc. | Application with multiple operation modes |
| CA2852916A1 (en) | 2011-10-17 | 2013-04-25 | Intertrust Technologies Corporation | Systems and methods for protecting and governing genomic and other information |
| US9137651B2 (en) * | 2011-11-22 | 2015-09-15 | International Business Machines Corporation | Systems and methods for determining relationships between mobile applications and electronic device users |
| JP5646125B1 (ja) * | 2011-12-02 | 2014-12-24 | エンパイア テクノロジー ディベロップメント エルエルシー | サービスとしての集積回路 |
| US8984273B2 (en) | 2011-12-16 | 2015-03-17 | Protected Mobility, Llc | Method to provide secure multimedia messaging between peer systems |
| CA2859794A1 (en) * | 2011-12-22 | 2013-06-27 | Abbvie Inc. | Application security framework |
| US9536105B2 (en) * | 2012-01-26 | 2017-01-03 | Nokia Technologies Oy | Method and apparatus for providing data access via multi-user views |
| US8745654B1 (en) | 2012-02-09 | 2014-06-03 | The Directv Group, Inc. | Method and system for managing digital rights for content |
| US8640190B1 (en) * | 2012-02-09 | 2014-01-28 | Symantec Corporation | Parental control policy generation |
| JP2015513830A (ja) | 2012-02-17 | 2015-05-14 | インタートラスト テクノロジーズ コーポレイション | 車両ポリシーエンフォースメントのためのシステム及び方法 |
| US9401904B1 (en) * | 2012-03-15 | 2016-07-26 | Motio, Inc. | Security migration in a business intelligence environment |
| US9503512B2 (en) | 2012-03-21 | 2016-11-22 | Intertrust Technologies Corporation | Distributed computation systems and methods |
| 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 |
| TWI626855B (zh) | 2012-04-27 | 2018-06-11 | 內數位專利控股公司 | 最佳化鄰近資料路徑設置方法及裝置 |
| CN104272707B (zh) * | 2012-04-27 | 2018-04-06 | 交互数字专利控股公司 | 支持邻近发现过程的方法和装置 |
| EP2859519A4 (en) * | 2012-06-11 | 2016-01-27 | Intertrust Tech Corp | SYSTEMS AND METHODS OF COLLECTING AND ANALYZING DATA |
| US9053318B2 (en) | 2012-07-17 | 2015-06-09 | CallSign, Inc. | Anti-cloning system and method |
| CA2879619A1 (en) | 2012-07-20 | 2014-01-23 | Intertrust Technologies Corporation | Information targeting systems and methods |
| US9160719B2 (en) | 2012-07-20 | 2015-10-13 | Protected Mobility, Llc | Hiding ciphertext using a linguistics algorithm with dictionaries |
| US9577986B1 (en) * | 2012-07-27 | 2017-02-21 | Daniel A Dooley | Secure data verification technique |
| EP2701090A1 (en) * | 2012-08-22 | 2014-02-26 | Aahlstö OÜ | Method and system for enforcing 3D restricted rights in a rapid manufacturing and prototyping environment |
| US8635373B1 (en) * | 2012-09-22 | 2014-01-21 | Nest Labs, Inc. | Subscription-Notification mechanisms for synchronization of distributed states |
| US8910239B2 (en) | 2012-10-15 | 2014-12-09 | Citrix Systems, Inc. | Providing virtualized private network tunnels |
| US9015212B2 (en) * | 2012-10-16 | 2015-04-21 | Rackspace Us, Inc. | System and method for exposing cloud stored data to a content delivery network |
| US9971585B2 (en) | 2012-10-16 | 2018-05-15 | Citrix Systems, Inc. | Wrapping unmanaged applications on a mobile device |
| US20140109072A1 (en) | 2012-10-16 | 2014-04-17 | Citrix Systems, Inc. | Application wrapping for application management framework |
| WO2014074513A1 (en) | 2012-11-06 | 2014-05-15 | Intertrust Technologies Corporation | Activity recognition systems and methods |
| CN104903908A (zh) | 2012-11-07 | 2015-09-09 | 英特托拉斯技术公司 | 个人数据管理系统及方法 |
| WO2014074722A1 (en) | 2012-11-07 | 2014-05-15 | Intertrust Technologies Corporation | Vehicle charging path optimization systems and methods |
| TWI463320B (zh) * | 2012-11-29 | 2014-12-01 | Mstar Semiconductor Inc | 記憶體存取權限控制方法與相關記憶體管理系統 |
| US9219791B2 (en) | 2012-12-13 | 2015-12-22 | Digiboo Llc | Digital filling station for digital locker content |
| US8560455B1 (en) * | 2012-12-13 | 2013-10-15 | Digiboo Llc | System and method for operating multiple rental domains within a single credit card domain |
| US10672046B2 (en) | 2012-12-31 | 2020-06-02 | Baker Hughes, A Ge Company, Llc | Systems and methods for non-destructive testing online stores |
| US9418050B1 (en) * | 2013-01-09 | 2016-08-16 | Pinterest, Inc. | Obtaining attribution information for representations |
| US9286644B2 (en) * | 2013-01-12 | 2016-03-15 | Pro Softnet Corporation | Method for sharing multiple data items using a single URL |
| US9576141B2 (en) | 2013-01-22 | 2017-02-21 | Amazon Technologies, Inc. | Access controls on the use of freeform metadata |
| US10341281B2 (en) | 2013-01-22 | 2019-07-02 | Amazon Technologies, Inc. | Access control policies associated with freeform metadata |
| US9530020B2 (en) * | 2013-01-22 | 2016-12-27 | Amazon Technologies, Inc. | Use of freeform metadata for access control |
| US10325298B2 (en) * | 2013-01-22 | 2019-06-18 | General Electric Company | Systems and methods for a non-destructive testing ecosystem |
| US9647838B2 (en) * | 2013-01-25 | 2017-05-09 | Ralph John Hilla | Restructuring the computer and its association with the internet |
| US9294485B2 (en) * | 2013-01-27 | 2016-03-22 | Dropbox, Inc. | Controlling access to shared content in an online content management system |
| CN105378774A (zh) | 2013-03-12 | 2016-03-02 | 英特托拉斯技术公司 | 安全交易系统和方法 |
| US9626489B2 (en) | 2013-03-13 | 2017-04-18 | Intertrust Technologies Corporation | Object rendering systems and methods |
| US9509688B1 (en) | 2013-03-13 | 2016-11-29 | EMC IP Holding Company LLC | Providing malicious identity profiles from failed authentication attempts involving biometrics |
| US9864873B2 (en) | 2013-03-15 | 2018-01-09 | Trustarc Inc | Managing data handling policies |
| US9565211B2 (en) | 2013-03-15 | 2017-02-07 | True Ultimate Standards Everywhere, Inc. | Managing exchanges of sensitive data |
| US20140282696A1 (en) * | 2013-03-15 | 2014-09-18 | Qualcomm Incorporated | Advertising download verification |
| US9159078B2 (en) | 2013-03-15 | 2015-10-13 | True Ultimate Standards Everywhere, Inc. | Managing identifiers |
| US8959595B2 (en) | 2013-03-15 | 2015-02-17 | Bullaproof, Inc. | Methods and systems for providing secure transactions |
| US10482397B2 (en) | 2013-03-15 | 2019-11-19 | Trustarc Inc | Managing identifiers |
| US9355223B2 (en) | 2013-03-29 | 2016-05-31 | Citrix Systems, Inc. | Providing a managed browser |
| US10284627B2 (en) | 2013-03-29 | 2019-05-07 | Citrix Systems, Inc. | Data management for an application with multiple operation modes |
| US9985850B2 (en) | 2013-03-29 | 2018-05-29 | Citrix Systems, Inc. | Providing mobile device management functionalities |
| US9306981B2 (en) | 2013-04-24 | 2016-04-05 | Intertrust Technologies Corporation | Bioinformatic processing systems and methods |
| US9721120B2 (en) * | 2013-05-14 | 2017-08-01 | Apple Inc. | Preventing unauthorized calls to a protected function |
| US9763067B2 (en) | 2013-05-28 | 2017-09-12 | Protected Mobility, Llc | Methods and apparatus for long-short wave, low-high frequency radio secure message service |
| US20160308839A1 (en) * | 2013-06-14 | 2016-10-20 | Richard Chuang | Piracy prevention and usage control system using access-controlled encrypted data containers |
| US9239933B2 (en) * | 2013-06-14 | 2016-01-19 | Richard Chuang | Piracy prevention and usage control system using access-controlled encrypted data containers |
| CN104254004A (zh) * | 2013-06-28 | 2014-12-31 | 中国科学院声学研究所 | 一种适合高码率音视频内容的数字版权保护方法和系统 |
| US9367339B2 (en) * | 2013-07-01 | 2016-06-14 | Amazon Technologies, Inc. | Cryptographically attested resources for hosting virtual machines |
| US9665895B2 (en) | 2013-08-12 | 2017-05-30 | Mov, Inc. | Technologies for video-based commerce |
| US9218437B1 (en) * | 2013-09-27 | 2015-12-22 | Amazon Technologies, Inc. | Systems and methods providing event data |
| US9361379B1 (en) | 2013-09-27 | 2016-06-07 | Amazon Technologies, Inc. | Systems and methods providing recommendation data |
| US9021606B1 (en) * | 2013-09-27 | 2015-04-28 | Amazon Technologies, Inc. | Systems and methods providing format data |
| US9178881B2 (en) * | 2013-10-09 | 2015-11-03 | Microsoft Technology Licensing, Llc | Proof of device genuineness |
| US10437830B2 (en) * | 2013-10-14 | 2019-10-08 | Nokia Technologies Oy | Method and apparatus for identifying media files based upon contextual relationships |
| US9391980B1 (en) * | 2013-11-11 | 2016-07-12 | Google Inc. | Enterprise platform verification |
| CN104767613B (zh) * | 2014-01-02 | 2018-02-13 | 腾讯科技（深圳）有限公司 | 签名验证方法、装置及系统 |
| WO2015116855A1 (en) | 2014-01-29 | 2015-08-06 | Intertrust Technologies Corporation | Secure application processing systems and methods |
| US9251334B1 (en) * | 2014-01-30 | 2016-02-02 | Amazon Technologies, Inc. | Enabling playback of media content |
| US9876991B1 (en) | 2014-02-28 | 2018-01-23 | Concurrent Computer Corporation | Hierarchical key management system for digital rights management and associated methods |
| JP2015203901A (ja) * | 2014-04-11 | 2015-11-16 | キヤノン株式会社 | 管理システム、情報処理装置、管理サーバ、それらの制御方法、およびプログラム |
| US10838378B2 (en) * | 2014-06-02 | 2020-11-17 | Rovio Entertainment Ltd | Control of a computer program using media content |
| US10162855B2 (en) | 2014-06-09 | 2018-12-25 | Dundas Data Visualization, Inc. | Systems and methods for optimizing data analysis |
| US20150378560A1 (en) * | 2014-06-30 | 2015-12-31 | Kobo Inc. | Unlocking content on a computing device from a preview |
| FR3024790B1 (fr) * | 2014-08-05 | 2016-09-09 | Bernard Gilbert Jean Marie France | Dispositif de transmission de courriers electroniques pour des terminaux non relies a un reseau informatique |
| US9398332B2 (en) * | 2014-08-14 | 2016-07-19 | Verizon Patent And Licensing Inc. | Checking in and checking out content from a media client device |
| EP3191949B1 (en) * | 2014-09-08 | 2020-06-10 | BlackBerry Limited | Shared lock state |
| US9806887B1 (en) * | 2014-09-23 | 2017-10-31 | Amazon Technologies, Inc. | Authenticating nonces prior to encrypting and decrypting cryptographic keys |
| WO2016118216A2 (en) | 2014-11-06 | 2016-07-28 | Intertrust Technologies Corporation | Secure application distribution systems and methods |
| US11244261B2 (en) | 2014-11-11 | 2022-02-08 | Amazon Technologies, Inc. | Catalog service platform for deploying applications and services |
| US10565534B2 (en) * | 2014-11-11 | 2020-02-18 | Amazon Technologies, Inc. | Constraints and constraint sharing in a catalog service platform |
| US20160173502A1 (en) * | 2014-12-15 | 2016-06-16 | International Business Machines Corporation | Jurisdictional cloud data access |
| WO2016112338A1 (en) | 2015-01-08 | 2016-07-14 | Intertrust Technologies Corporation | Cryptographic systems and methods |
| US9996680B2 (en) * | 2015-01-18 | 2018-06-12 | F. Scott Deaver | Methods and related apparatus for managing access to digital assets |
| US9516000B2 (en) * | 2015-03-27 | 2016-12-06 | International Business Machines Corporation | Runtime instantiation of broadcast encryption schemes |
| US11762989B2 (en) * | 2015-06-05 | 2023-09-19 | Bottomline Technologies Inc. | Securing electronic data by automatically destroying misdirected transmissions |
| US20160364553A1 (en) * | 2015-06-09 | 2016-12-15 | Intel Corporation | System, Apparatus And Method For Providing Protected Content In An Internet Of Things (IOT) Network |
| US10389716B2 (en) | 2015-07-29 | 2019-08-20 | RegDOX Solutions Inc. | Secure document storage system |
| EP3347868A4 (en) * | 2015-09-09 | 2019-04-17 | Mastercard International Incorporated | METHOD AND SYSTEM FOR THE INTELLIGENT STORAGE AND DISTRIBUTION OF MEDIA KEYS FOR CONTINUOUS SUPPLY |
| US9467726B1 (en) | 2015-09-30 | 2016-10-11 | The Directv Group, Inc. | Systems and methods for provisioning multi-dimensional rule based entitlement offers |
| US9848214B2 (en) | 2015-10-01 | 2017-12-19 | Sorenson Media, Inc. | Sequentially overlaying media content |
| US9723347B2 (en) | 2015-10-01 | 2017-08-01 | Sorenson Media, Inc | Frequency capping for media content |
| US10317243B2 (en) | 2015-10-15 | 2019-06-11 | Intertrust Technologies Corporation | Sensor information management systems and methods |
| US20170109537A1 (en) * | 2015-10-16 | 2017-04-20 | Fraunhofer-Gesellschaft Zur Foerderung Der Angewandten Forschung E.V. | Vorrichtung, die zugriffsschutz fuer strukturhaltige verteilte daten realisiert |
| US10599817B2 (en) | 2016-03-08 | 2020-03-24 | Adobe Inc. | Portion-level digital rights management in digital content |
| US10346594B2 (en) | 2016-03-24 | 2019-07-09 | Adobe Inc. | Digital rights management leveraging motion or environmental traits |
| US20170278206A1 (en) * | 2016-03-24 | 2017-09-28 | Adobe Systems Incorporated | Digital Rights Management and Updates |
| US10460082B2 (en) | 2016-04-04 | 2019-10-29 | Adobe Inc. | Digital rights management progressive control and background processing |
| EP3455763B1 (en) * | 2016-05-12 | 2020-12-30 | Koninklijke Philips N.V. | Digital rights management for anonymous digital content sharing |
| US10182387B2 (en) | 2016-06-01 | 2019-01-15 | At&T Intellectual Property I, L.P. | Method and apparatus for distributing content via diverse networks |
| WO2017222428A1 (en) * | 2016-06-20 | 2017-12-28 | Obschestvo S Ogranichennoi Otvetstvennostyu "Teleport Rus" | Method and system of content distribution in the data transfer network |
| RU2647635C2 (ru) * | 2016-06-20 | 2018-03-16 | Общество с ограниченной ответственностью "Телепорт Русь" (ООО "Телепорт Русь") | Способ и система распространения контента в сети передачи данных со встроенным механизмом условного доступа |
| US11868445B2 (en) * | 2016-06-24 | 2024-01-09 | Discovery Communications, Llc | Systems and methods for federated searches of assets in disparate dam repositories |
| US10372883B2 (en) * | 2016-06-24 | 2019-08-06 | Scripps Networks Interactive, Inc. | Satellite and central asset registry systems and methods and rights management systems |
| US11157641B2 (en) * | 2016-07-01 | 2021-10-26 | Microsoft Technology Licensing, Llc | Short-circuit data access |
| EP3287931A1 (en) * | 2016-08-22 | 2018-02-28 | Keyp GmbH | Data guard system |
| EP3287919A1 (en) * | 2016-08-22 | 2018-02-28 | Keyp GmbH | Data guard system |
| US20190207943A1 (en) * | 2016-08-22 | 2019-07-04 | Keyp Gmbh | Data guard system |
| US10607025B2 (en) | 2016-09-15 | 2020-03-31 | PeerNova, Inc. | Access control through data structures |
| US10218704B2 (en) | 2016-10-06 | 2019-02-26 | Cisco Technology, Inc. | Resource access control using named capabilities |
| US11334852B2 (en) * | 2016-12-08 | 2022-05-17 | Airwatch Llc | Secured attachment management |
| US10313223B2 (en) * | 2016-12-14 | 2019-06-04 | Level 3 Communications, Llc | Object integrity verification in a content delivery network (CDN) |
| JP6802572B2 (ja) * | 2016-12-26 | 2020-12-16 | 国立大学法人大阪大学 | データ解析方法およびデータ解析システム |
| US10965474B1 (en) * | 2017-02-27 | 2021-03-30 | Apple Inc. | Modifying security state with highly secured devices |
| US11954071B1 (en) * | 2017-06-11 | 2024-04-09 | Jennifer Shin | File naming and management system |
| US10756898B2 (en) | 2017-06-12 | 2020-08-25 | Rebel AI LLC | Content delivery verification |
| IT201700087238A1 (it) * | 2017-07-28 | 2019-01-28 | Alessandro Capuzzello | Sistema elettronico per autenticazione sicura dell’identità di un utente |
| JP6892361B2 (ja) | 2017-09-21 | 2021-06-23 | キオクシア株式会社 | ストレージ装置 |
| EP3486772A1 (en) * | 2017-11-16 | 2019-05-22 | Siemens Aktiengesellschaft | Method for reciprocally integrating applications in an industrial program-control system |
| US10693662B2 (en) * | 2018-02-22 | 2020-06-23 | Idlogiq Inc. | Methods for secure serialization of supply chain product units |
| CN108389059A (zh) * | 2018-02-26 | 2018-08-10 | 成都大学 | 基于权属的数字版权作品保护、交易和发行方法及系统 |
| US10839050B2 (en) * | 2018-03-08 | 2020-11-17 | Microsoft Technology Licensing, Llc | Activation of an application based on prior activation of an isolated counterpart application |
| RU181439U1 (ru) * | 2018-04-06 | 2018-07-13 | Оксана Валерьевна Кириченко | Децентрализованная технологическая платформа хранения и обмена данными транзакций в распределенной вычислительной сети |
| US11362824B2 (en) * | 2018-05-25 | 2022-06-14 | Intertrust Technologies Corporation | Content management systems and methods using proxy reencryption |
| US11748455B2 (en) * | 2018-05-25 | 2023-09-05 | Intertrust Technologies Corporation | Digital rights management systems and methods using efficient messaging architectures |
| US20200242213A1 (en) * | 2019-01-28 | 2020-07-30 | Blackberry Limited | Method and system for digital rights management |
| US11636220B2 (en) * | 2019-02-01 | 2023-04-25 | Intertrust Technologies Corporation | Data management systems and methods |
| RU189720U1 (ru) * | 2019-02-20 | 2019-05-31 | Смаль Алексей Игоревич | Технологическая платформа интеграции игровых ресурсов сети Интернет для покупки пользователями товаров и услуг |
| KR102250124B1 (ko) * | 2019-03-08 | 2021-05-10 | 임근만 | 수제맥주 제조장치와 제조플렛폼 및 이를 이용한 수제맥주 제조방법 |
| US11356283B2 (en) * | 2019-05-08 | 2022-06-07 | Seagate Technology Llc | Data storage using an encryption key with a time expiration associated therewith |
| US10904251B2 (en) | 2019-05-17 | 2021-01-26 | Advanced New Technologies Co., Ltd. | Blockchain-based copyright protection method and apparatus, and electronic device |
| EP3745640A1 (en) * | 2019-05-31 | 2020-12-02 | Siemens Aktiengesellschaft | Establishing secure communication without local time information |
| JP7335591B2 (ja) * | 2019-07-22 | 2023-08-30 | コネクトフリー株式会社 | コンピューティングシステムおよび情報処理方法 |
| US20210056053A1 (en) * | 2019-08-19 | 2021-02-25 | Cryptography Research, Inc. | Application authentication and data encryption without stored pre-shared keys |
| JP2021044646A (ja) * | 2019-09-10 | 2021-03-18 | シャープ株式会社 | 情報処理システム、情報処理方法、及び情報処理プログラム |
| US10764732B1 (en) * | 2019-09-30 | 2020-09-01 | At&T Intellectual Property I, L.P. | Methods, systems, and devices for providing subscription services for a communication device using an operational profile |
| US10856121B1 (en) | 2019-10-22 | 2020-12-01 | At&T Intellectual Property I, L.P. | Methods, systems, and devices for providing subscription services to a communication device that shares an operational profile with another communication device |
| US10834574B1 (en) | 2019-11-04 | 2020-11-10 | At&T Intellectual Property I, L.P. | Methods, systems, and devices for obtaining a profile enabling establishment of an active subscription for services of a mobile network |
| US11159927B2 (en) | 2019-11-04 | 2021-10-26 | At&T Intellectual Property I, L.P. | Methods, systems, and devices for establishing an active subscription for services of a mobile network |
| US11381658B2 (en) | 2019-11-08 | 2022-07-05 | At&T Intellectual Property I, L.P. | Managing devices through use of blocks of operational profiles |
| US11516192B2 (en) * | 2019-12-19 | 2022-11-29 | Augustine Fou | System and method for combinatorial security |
| CN113014531B (zh) * | 2019-12-20 | 2022-11-29 | 中标软件有限公司 | 一种应用于电子邮件数据加密传输的方法 |
| US20210243035A1 (en) * | 2020-02-03 | 2021-08-05 | Micron Technology, Inc. | Multi-factor authentication enabled memory sub-system |
| WO2021178900A1 (en) | 2020-03-06 | 2021-09-10 | Christopher Renwick Alston | Technologies for augmented-reality |
| US11151229B1 (en) | 2020-04-10 | 2021-10-19 | Avila Technology, LLC | Secure messaging service with digital rights management using blockchain technology |
| US10873852B1 (en) | 2020-04-10 | 2020-12-22 | Avila Technology, LLC | POOFster: a secure mobile text message and object sharing application, system, and method for same |
| KR102472893B1 (ko) * | 2020-10-08 | 2022-11-30 | 명지대학교 산학협력단 | 미디어 사물인터넷에서 미션 다이어그램을 이용한 미디어사물의 미션을 수행하기 위한 시스템, 이를 위한 방법 및 이 방법을 수행하는 프로그램이 기록된 컴퓨터 판독 가능한 기록매체 |
| WO2022164899A1 (en) * | 2021-01-29 | 2022-08-04 | Docusign, Inc. | Document package modifications based on assigned permissions in a document management platform |
| KR102547745B1 (ko) * | 2021-07-12 | 2023-06-26 | 주식회사 아이디스 | 사전 인증정보를 이용해 네트워크 응답속도를 개선한 영상 보안 시스템 |
| WO2023003699A1 (en) * | 2021-07-21 | 2023-01-26 | Liveramp, Inc. | Publisher permissioned activation in cookieless authentication environment |
| US20230046788A1 (en) * | 2021-08-16 | 2023-02-16 | Capital One Services, Llc | Systems and methods for resetting an authentication counter |
| US20230161795A1 (en) * | 2021-11-19 | 2023-05-25 | Intertrust Technologies Corporation | Time series data management systems and methods |
| KR102654259B1 (ko) * | 2023-08-14 | 2024-04-04 | 광운대학교 산학협력단 | 온라인 및 오프라인 유통을 위한 암호화 기반 콘텐츠 서비스 시스템 |
Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2003034408A2 (en) * | 2001-10-18 | 2003-04-24 | Nokia Corporation | System and method for controlled copying and moving of contents |
| WO2004008297A1 (en) * | 2002-07-11 | 2004-01-22 | University Of Wollongong | Methods for standard mechanisms for digital item manipulation and handling |
| WO2004027588A2 (en) * | 2002-09-23 | 2004-04-01 | Koninklijke Philips Electronics N.V. | Certificate based authorized domains |
| WO2004038568A2 (en) * | 2002-10-22 | 2004-05-06 | Koninklijke Philips Electronics N.V. | Method and device for authorizing content operations |
| WO2004059451A1 (en) * | 2002-12-30 | 2004-07-15 | Koninklijke Philips Electronics N.V. | Divided rights in authorized domain |
Family Cites Families (214)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US4827508A (en) * | 1986-10-14 | 1989-05-02 | Personal Library Software, Inc. | Database usage metering and protection system and method |
| US5050213A (en) | 1986-10-14 | 1991-09-17 | Electronic Publishing Resources, Inc. | Database usage metering and protection system and method |
| US4977594A (en) | 1986-10-14 | 1990-12-11 | Electronic Publishing Resources, 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 |
| US5126746A (en) * | 1991-07-08 | 1992-06-30 | The United States Of America As Represented By The United States Department Of Energy | Secure distance ranging by electronic means |
| US6850252B1 (en) * | 1999-10-05 | 2005-02-01 | Steven M. Hoffberg | Intelligent electronic appliance system and method |
| US5414845A (en) * | 1992-06-26 | 1995-05-09 | International Business Machines Corporation | Network-based computer system with improved network scheduling system |
| JPH07230380A (ja) | 1994-02-15 | 1995-08-29 | Internatl Business Mach Corp <Ibm> | 適用業務プログラムの利用管理方法およびシステム |
| JPH07319691A (ja) | 1994-03-29 | 1995-12-08 | Toshiba Corp | 資源保護装置、特権保護装置、ソフトウェア利用法制御装置、及びソフトウェア利用法制御システム |
| 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 |
| US5629980A (en) * | 1994-11-23 | 1997-05-13 | Xerox Corporation | System for controlling the distribution and use of digital works |
| US5638443A (en) * | 1994-11-23 | 1997-06-10 | Xerox Corporation | System for controlling the distribution and use of composite digital works |
| JPH08263438A (ja) | 1994-11-23 | 1996-10-11 | Xerox Corp | ディジタルワークの配給及び使用制御システム並びにディジタルワークへのアクセス制御方法 |
| 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 |
| 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 |
| US7124302B2 (en) * | 1995-02-13 | 2006-10-17 | Intertrust Technologies Corp. | Systems and methods for secure transaction management and electronic rights protection |
| US6948070B1 (en) * | 1995-02-13 | 2005-09-20 | Intertrust Technologies Corporation | Systems and methods for secure transaction management and electronic rights protection |
| US5892900A (en) | 1996-08-30 | 1999-04-06 | Intertrust Technologies Corp. | Systems and methods for secure transaction management and electronic rights protection |
| 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 |
| 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 |
| US7069451B1 (en) * | 1995-02-13 | 2006-06-27 | Intertrust Technologies Corp. | Systems and methods for secure transaction management and electronic rights protection |
| WO1996027155A2 (en) | 1995-02-13 | 1996-09-06 | Electronic Publishing Resources, Inc. | 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 |
| US5534975A (en) | 1995-05-26 | 1996-07-09 | Xerox Corporation | Document processing system utilizing document service cards to provide document processing services |
| US5774652A (en) * | 1995-09-29 | 1998-06-30 | Smith; Perry | Restricted access computer system |
| US5765152A (en) | 1995-10-13 | 1998-06-09 | Trustees Of Dartmouth College | System and method for managing copyrighted electronic media |
| US6807534B1 (en) | 1995-10-13 | 2004-10-19 | Trustees Of Dartmouth College | System and method for managing copyrighted electronic media |
| ATE448532T1 (de) | 1996-09-04 | 2009-11-15 | Intertrust Tech Corp | Zuverlässige infrastrukturhilfssysteme, verfahren und techniken für sicheren elektronischen handel, elektronische transaktionen, handelsablaufsteuerung und automatisierung, verteilte verarbeitung und rechteverwaltung |
| 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 |
| US6006332A (en) * | 1996-10-21 | 1999-12-21 | Case Western Reserve University | Rights management system for digital media |
| JPH10133955A (ja) | 1996-10-29 | 1998-05-22 | Matsushita Electric Ind Co Ltd | 可搬型メディア駆動装置とその方法、及び可搬型メディアとネットワークの連携装置とその方法 |
| 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 |
| 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 |
| 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 |
| CA2293650C (en) | 1997-06-09 | 2012-09-25 | Christian Sven Collberg | Obfuscation techniques for enhancing software security |
| US6188995B1 (en) * | 1997-07-28 | 2001-02-13 | Apple Computer, Inc. | Method and apparatus for enforcing software licenses |
| US6044468A (en) * | 1997-08-25 | 2000-03-28 | Emc Corporation | Secure transmission using an ordinarily insecure network communication protocol such as SNMP |
| US6044469A (en) * | 1997-08-29 | 2000-03-28 | Preview Software | Software publisher or distributor configurable software security mechanism |
| 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 |
| US7092914B1 (en) | 1997-11-06 | 2006-08-15 | Intertrust Technologies Corporation | Methods for matching, selecting, narrowcasting, and/or classifying based on rights management and/or other information |
| US6065120A (en) * | 1997-12-09 | 2000-05-16 | Phone.Com, Inc. | Method and system for self-provisioning a rendezvous to ensure secure access to information in a database from multiple devices |
| 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 |
| US6233577B1 (en) * | 1998-02-17 | 2001-05-15 | Phone.Com, Inc. | Centralized certificate management system for two-way interactive communication devices in data networks |
| WO1999048296A1 (en) | 1998-03-16 | 1999-09-23 | Intertrust Technologies Corporation | Methods and apparatus for continuous control and protection of media content |
| US7809138B2 (en) | 1999-03-16 | 2010-10-05 | Intertrust Technologies Corporation | Methods and apparatus for persistent control and protection of content |
| US7606355B2 (en) * | 1998-04-22 | 2009-10-20 | Echarge Corporation | Method and apparatus for ordering goods, services and content over an internetwork |
| US20040107368A1 (en) * | 1998-06-04 | 2004-06-03 | Z4 Technologies, Inc. | Method for digital rights management including self activating/self authentication software |
| 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 |
| US7058414B1 (en) | 2000-05-26 | 2006-06-06 | Freescale Semiconductor, Inc. | Method and system for enabling device functions based on distance information |
| US6223291B1 (en) * | 1999-03-26 | 2001-04-24 | Motorola, Inc. | Secure wireless electronic-commerce system with digital product certificates and digital license certificates |
| US20020198791A1 (en) | 1999-04-21 | 2002-12-26 | Perkowski Thomas J. | Internet-based consumer product brand marketing communication system which enables manufacturers, retailers and their respective agents, and consumers to carry out product-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 |
| US6785815B1 (en) | 1999-06-08 | 2004-08-31 | Intertrust Technologies Corp. | Methods and systems for encoding and protecting data using digital signature and watermarking techniques |
| US7152165B1 (en) | 1999-07-16 | 2006-12-19 | Intertrust Technologies Corp. | Trusted storage systems and methods |
| US7430670B1 (en) | 1999-07-29 | 2008-09-30 | Intertrust Technologies Corp. | Software self-defense systems and methods |
| US7124170B1 (en) | 1999-08-20 | 2006-10-17 | Intertrust Technologies Corp. | Secure processing unit systems and methods |
| US20080133417A1 (en) * | 1999-10-18 | 2008-06-05 | Emergent Music Llc | System to determine quality through reselling of items |
| US6842863B1 (en) * | 1999-11-23 | 2005-01-11 | Microsoft Corporation | Certificate reissuance for checking the status of a certificate in financial transactions |
| US6832316B1 (en) * | 1999-12-22 | 2004-12-14 | Intertrust Technologies, Corp. | Systems and methods for protecting data secrecy and integrity |
| US20010033554A1 (en) | 2000-02-18 | 2001-10-25 | Arun Ayyagari | Proxy-bridge connecting remote users to a limited connectivity network |
| US7426750B2 (en) | 2000-02-18 | 2008-09-16 | Verimatrix, Inc. | Network-based content distribution system |
| IL135555A0 (en) * | 2000-04-09 | 2001-05-20 | Vidius Inc | Preventing unauthorized access to data sent via computer networks |
| JP3711866B2 (ja) | 2000-04-10 | 2005-11-02 | 日本電気株式会社 | プラグアンドプレイ機能を有するフレームワークおよびその再構成方法 |
| AU2001259590A1 (en) | 2000-05-08 | 2001-11-20 | 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 |
| US6961858B2 (en) | 2000-06-16 | 2005-11-01 | Entriq, Inc. | Method and system to secure content for distribution via a network |
| US6990513B2 (en) * | 2000-06-22 | 2006-01-24 | Microsoft Corporation | Distributed computing services platform |
| WO2002003604A2 (en) * | 2000-06-29 | 2002-01-10 | Cachestream Corporation | Digital rights management |
| WO2002005061A2 (en) | 2000-07-06 | 2002-01-17 | David Paul Felsher | Information record infrastructure, system and method |
| 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 |
| JP2002073861A (ja) * | 2000-08-24 | 2002-03-12 | Matsushita Electric Ind Co Ltd | 情報配信制御方法 |
| 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 |
| JP4269501B2 (ja) * | 2000-09-07 | 2009-05-27 | ソニー株式会社 | 情報記録装置、情報再生装置、情報記録方法、情報再生方法、および情報記録媒体、並びにプログラム提供媒体 |
| GB2366969A (en) * | 2000-09-14 | 2002-03-20 | Phocis Ltd | Copyright protection for digital content distributed over a network |
| US7171558B1 (en) * | 2000-09-22 | 2007-01-30 | International Business Machines Corporation | Transparent digital rights management for extendible content viewers |
| GB0024918D0 (en) | 2000-10-11 | 2000-11-22 | Sealedmedia Ltd | Method of providing java tamperproofing |
| GB0024919D0 (en) * | 2000-10-11 | 2000-11-22 | Sealedmedia Ltd | Method of further securing an operating system |
| SE519748C2 (sv) | 2000-10-23 | 2003-04-08 | Volvo Technology Corp | Förfarande för kontroll av behörighet för tillträde till ett objekt samt datorprogramprodukten för utförande av förfaranden |
| US8606684B2 (en) * | 2000-11-10 | 2013-12-10 | Aol Inc. | Digital content distribution and subscription system |
| 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 |
| 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 |
| US7774279B2 (en) * | 2001-05-31 | 2010-08-10 | Contentguard Holdings, Inc. | Rights offering and granting |
| US20030220880A1 (en) | 2002-01-17 | 2003-11-27 | Contentguard Holdings, Inc. | Networked services licensing system and method |
| US7395430B2 (en) * | 2001-08-28 | 2008-07-01 | International Business Machines Corporation | Secure authentication using digital certificates |
| 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 |
| WO2002076003A2 (en) | 2001-03-19 | 2002-09-26 | Imesh Ltd. | System and method for peer-to-peer file exchange mechanism from multiple sources |
| US7065507B2 (en) * | 2001-03-26 | 2006-06-20 | Microsoft Corporation | Supervised license acquisition in a digital rights management system on a computing device |
| WO2002077747A2 (en) * | 2001-03-27 | 2002-10-03 | Microsoft Corporation | Distributed, scalable cryptographic access control |
| 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 |
| KR100911282B1 (ko) * | 2001-03-29 | 2009-08-11 | 소니 가부시끼 가이샤 | 정보 처리 장치 |
| 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 |
| US7516325B2 (en) * | 2001-04-06 | 2009-04-07 | Certicom Corp. | Device authentication in a PKI |
| ATE467973T1 (de) | 2001-04-12 | 2010-05-15 | Research In Motion Ltd | System und verfahren zum dynamischen schieben von informationen auf drahtlose datenübertragungsvorrichtungen |
| US20020157002A1 (en) | 2001-04-18 | 2002-10-24 | Messerges Thomas S. | System and method for secure and convenient management of digital 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 |
| 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 |
| US6895503B2 (en) * | 2001-05-31 | 2005-05-17 | Contentguard Holdings, Inc. | Method and apparatus for hierarchical assignment of rights to documents and documents having such rights |
| US7581103B2 (en) | 2001-06-13 | 2009-08-25 | Intertrust Technologies Corporation | Software self-checking systems and methods |
| US7900042B2 (en) * | 2001-06-26 | 2011-03-01 | Ncipher Corporation Limited | Encrypted packet inspection |
| 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 |
| US8352582B2 (en) * | 2001-06-28 | 2013-01-08 | Koninklijke Philips Electronics N.V. | Temporal proximity to verify physical proximity |
| US7421411B2 (en) * | 2001-07-06 | 2008-09-02 | Nokia Corporation | 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 |
| JP4280036B2 (ja) | 2001-08-03 | 2009-06-17 | パナソニック株式会社 | アクセス権制御システム |
| US20030037139A1 (en) * | 2001-08-20 | 2003-02-20 | Koninklijke Philips Electronics N.V. | Content distribution model |
| US7035944B2 (en) | 2001-09-19 | 2006-04-25 | International Business Machines Corporation | Programmatic management of software resources in a content framework environment |
| CA2404550C (en) * | 2001-09-21 | 2010-02-09 | Corel Corporation | System and method for web services packaging |
| 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 |
| US20030079133A1 (en) * | 2001-10-18 | 2003-04-24 | International Business Machines Corporation | Method and system for digital rights management in content distribution application |
| US20030078891A1 (en) * | 2001-10-18 | 2003-04-24 | Capitant Patrice J. | Systems and methods for providing digital rights management compatibility |
| CN1579095A (zh) * | 2001-10-29 | 2005-02-09 | 松下电器产业株式会社 | 基线内容保护和复制管理数字视频广播的装置 |
| US7496751B2 (en) * | 2001-10-29 | 2009-02-24 | Sun Microsystems, Inc. | Privacy and identification in a data communications network |
| EP1485833A4 (en) | 2001-11-20 | 2005-10-12 | Contentguard Holdings Inc | EXTENSIBLE RIGHTS EXPRESSION PROCESSING SYSTEM |
| US7254614B2 (en) | 2001-11-20 | 2007-08-07 | Nokia Corporation | Web services push gateway |
| US20030126086A1 (en) * | 2001-12-31 | 2003-07-03 | General Instrument Corporation | Methods and apparatus for digital rights management |
| JP4039489B2 (ja) * | 2002-01-12 | 2008-01-30 | コアトラスト インコーポレーテッド | マルチメディアコンテンツの情報保護方法及びシステム |
| US7496757B2 (en) * | 2002-01-14 | 2009-02-24 | International Business Machines Corporation | Software verification system, method and computer program element |
| 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 |
| US6996544B2 (en) * | 2002-02-27 | 2006-02-07 | Imagineer Software, Inc. | Multiple party content distribution system and method with rights management features |
| KR100467929B1 (ko) | 2002-02-28 | 2005-01-24 | 주식회사 마크애니 | 디지털 컨텐츠의 보호 및 관리를 위한 시스템 |
| 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 |
| US7383570B2 (en) * | 2002-04-25 | 2008-06-03 | Intertrust Technologies, Corp. | Secure authentication systems and methods |
| US7149899B2 (en) * | 2002-04-25 | 2006-12-12 | Intertrust Technologies Corp. | Establishing a secure channel with a human user |
| 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 |
| AU2003267975A1 (en) * | 2002-06-27 | 2004-01-19 | Piranha Media Distribution, Inc. | Method and apparatus for the free licensing of digital media content |
| US7631318B2 (en) * | 2002-06-28 | 2009-12-08 | Microsoft Corporation | Secure server plug-in architecture for digital rights management systems |
| US7353402B2 (en) * | 2002-06-28 | 2008-04-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 |
| US7401221B2 (en) | 2002-09-04 | 2008-07-15 | Microsoft Corporation | Advanced stream format (ASF) data stream header object protection |
| US20040216127A1 (en) | 2002-09-10 | 2004-10-28 | Chutney Technologies | Method and apparatus for accelerating web services |
| US7991998B2 (en) | 2002-09-30 | 2011-08-02 | Koninklijke Philips Electronics N.V. | Secure proximity verification of a node on a network |
| US20040088541A1 (en) * | 2002-11-01 | 2004-05-06 | Thomas Messerges | Digital-rights management system |
| 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 |
| US7899187B2 (en) * | 2002-11-27 | 2011-03-01 | Motorola Mobility, Inc. | Domain-based digital-rights management system with easy and secure device enrollment |
| 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 |
| US7493289B2 (en) * | 2002-12-13 | 2009-02-17 | Aol Llc | Digital content store system |
| JP2006510102A (ja) | 2002-12-17 | 2006-03-23 | コーニンクレッカ フィリップス エレクトロニクス エヌ ヴィ | コンテンツの分配を許容するシステム |
| US8364951B2 (en) | 2002-12-30 | 2013-01-29 | General Instrument Corporation | System for digital rights management using distributed provisioning and authentication |
| 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) |
| JP4284497B2 (ja) * | 2003-01-29 | 2009-06-24 | 日本電気株式会社 | 情報共有方法、装置、およびプログラム |
| US20050004873A1 (en) | 2003-02-03 | 2005-01-06 | Robin Pou | Distribution and rights management of digital content |
| 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 |
| 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 |
| US7308573B2 (en) * | 2003-02-25 | 2007-12-11 | Microsoft Corporation | Enrolling / sub-enrolling a digital rights management (DRM) server into a DRM architecture |
| US7577964B2 (en) * | 2003-02-28 | 2009-08-18 | Hewlett-Packard Development Company, L.P. | System and methods for defining a binding for web-services |
| US20040205333A1 (en) * | 2003-04-14 | 2004-10-14 | Telefonaktiebolaget Lm Ericsson (Publ) | Method and system for digital rights management |
| CA2527668A1 (en) * | 2003-06-02 | 2004-12-16 | Liquid Machines, Inc. | Managing data objects in dynamic, distributed and collaborative contexts |
| EA015549B1 (ru) * | 2003-06-05 | 2011-08-30 | Интертраст Текнолоджис Корпорейшн | Переносимая система и способ для приложений одноранговой компоновки услуг |
| 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 (ja) * | 2003-06-16 | 2005-01-13 | Toshiba Corp | 電子商品流通システム、電子商品受信端末、及び電子商品流通方法 |
| 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 |
| RU2006110943A (ru) | 2003-09-05 | 2006-08-10 | Лаймлайт Нетворск, Инк. (Us) | Управление лицензиями на цифровой контент |
| US7389273B2 (en) | 2003-09-25 | 2008-06-17 | Scott Andrew Irwin | System and method for federated rights management |
| 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 |
| EP1688843A1 (en) | 2003-11-25 | 2006-08-09 | Matsushita Electric Industrial Co., Ltd. | Authentication system |
| US20050234735A1 (en) | 2003-11-26 | 2005-10-20 | Williams Jim C | Digital rights management using proximity testing |
| US7516331B2 (en) * | 2003-11-26 | 2009-04-07 | International Business Machines Corporation | Tamper-resistant trusted java virtual machine and method of using the same |
| US20050192902A1 (en) * | 2003-12-05 | 2005-09-01 | Motion Picture Association Of America | Digital rights management using multiple independent parameters |
| KR100597401B1 (ko) * | 2004-02-06 | 2006-07-06 | 삼성전자주식회사 | 컨텐츠 저작권 보호를 위한 ｄｒｍ 관리 방법 및 그 장치 |
| US20050177516A1 (en) | 2004-02-06 | 2005-08-11 | Eric Vandewater | System and method of protecting digital content |
| US7676846B2 (en) * | 2004-02-13 | 2010-03-09 | Microsoft Corporation | Binding content to an entity |
| WO2005081895A2 (en) | 2004-02-23 | 2005-09-09 | Hillcrest Laboratories, Inc. | Methods and systems for a secure media computing environment |
| JP4350549B2 (ja) | 2004-02-25 | 2009-10-21 | 富士通株式会社 | デジタル著作権管理のための情報処理装置 |
| JP4466148B2 (ja) * | 2004-03-25 | 2010-05-26 | 株式会社日立製作所 | ネットワーク転送対応コンテンツ利用管理方法、及びプログラム、コンテンツ転送システム |
| 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 |
| US7711647B2 (en) * | 2004-06-10 | 2010-05-04 | Akamai Technologies, Inc. | Digital rights management in a distributed network |
| US20050278256A1 (en) | 2004-06-15 | 2005-12-15 | Eric Vandewater | System and method of promoting copy-managed digital content |
| GB0413848D0 (en) * | 2004-06-21 | 2004-07-21 | British Broadcasting Corp | Accessing broadcast media |
| AU2005273532B2 (en) | 2004-06-28 | 2011-04-07 | Acano (Uk) Limited | System for proximity determination |
| US20060015580A1 (en) * | 2004-07-01 | 2006-01-19 | Home Box Office, A Delaware Corporation | Multimedia content distribution |
| US7711120B2 (en) * | 2004-07-29 | 2010-05-04 | Infoassure, Inc. | Cryptographic key management |
| US7610011B2 (en) * | 2004-09-19 | 2009-10-27 | Adam Albrett | Providing alternative programming on a radio in response to user input |
| KR100677152B1 (ko) | 2004-11-17 | 2007-02-02 | 삼성전자주식회사 | 사용자 바인딩을 이용한 홈 네트워크에서의 콘텐츠 전송방법 |
| CN1290349C (zh) * | 2004-11-30 | 2006-12-13 | 北京中星微电子有限公司 | 一种具有数字版权保护和认证的移动通信系统及方法 |
| EP1672831A1 (fr) * | 2004-12-16 | 2006-06-21 | Nagravision S.A. | Méthode de transmission de données numériques dans un réseau local |
| KR100694104B1 (ko) | 2005-02-23 | 2007-03-12 | 삼성전자주식회사 | 라운드 트립 시간을 측정하는 방법 및 이를 이용한 인접성검사 방법 |
| US8302178B2 (en) * | 2005-03-07 | 2012-10-30 | Noam Camiel | System and method for a dynamic policies enforced file system for a data storage device |
| KR100636232B1 (ko) | 2005-04-29 | 2006-10-18 | 삼성전자주식회사 | 해시 체인을 이용하여 디바이스들간의 인접성을 검사하는방법 및 장치 |
| US20060294580A1 (en) * | 2005-06-28 | 2006-12-28 | Yeh Frank Jr | Administration of access to computer resources on a network |
| US8239682B2 (en) * | 2005-09-28 | 2012-08-07 | Nl Systems, Llc | Method and system for digital rights management of documents |
| WO2007043015A2 (en) | 2005-10-13 | 2007-04-19 | Koninklijke Philips Electronics N.V. | Improved proximity detection method |
| KR100736080B1 (ko) * | 2005-10-27 | 2007-07-06 | 삼성전자주식회사 | 다 계층으로 구성된 멀티미디어 스트림의 저작권을 계층별로 관리하는 방법 및 장치 |
| KR100828370B1 (ko) | 2006-10-20 | 2008-05-08 | 삼성전자주식회사 | Ｄｒｍ 컨텐츠 및 라이센스 제공 방법 및 장치, 그리고ｄｒｍ 컨텐츠 사용 방법 및 장치 |
| US7953882B2 (en) * | 2007-07-26 | 2011-05-31 | Realnetworks, Inc. | Adaptive variable fidelity media distribution system and method |
| US7831571B2 (en) * | 2007-10-25 | 2010-11-09 | International Business Machines Corporation | Anonymizing selected content in a document |
| US10230605B1 (en) | 2018-09-04 | 2019-03-12 | Cisco Technology, Inc. | Scalable distributed end-to-end performance delay measurement for segment routing policies |
-
2006
- 2006-10-18 JP JP2008536800A patent/JP2009512096A/ja not_active Withdrawn
- 2006-10-18 KR KR1020117030396A patent/KR101285024B1/ko active IP Right Grant
- 2006-10-18 EP EP09156631.5A patent/EP2090998B1/en active Active
- 2006-10-18 EP EP06826285A patent/EP1943603A2/en not_active Ceased
- 2006-10-18 US US11/583,695 patent/US20070172041A1/en not_active Abandoned
- 2006-10-18 EA EA200901153A patent/EA200901153A1/ru unknown
- 2006-10-18 KR KR1020127015783A patent/KR101285946B1/ko active IP Right Grant
- 2006-10-18 EP EP09156727A patent/EP2124164A3/en not_active Withdrawn
- 2006-10-18 WO PCT/US2006/040898 patent/WO2007047846A2/en active Application Filing
- 2006-10-18 CA CA002626244A patent/CA2626244A1/en not_active Abandoned
- 2006-10-18 CN CN201110009994XA patent/CN102073819B/zh not_active Expired - Fee Related
- 2006-10-18 EA EA200801117A patent/EA012918B1/ru not_active IP Right Cessation
- 2006-10-18 EP EP09156702A patent/EP2128780A3/en not_active Ceased
- 2006-10-18 US US11/583,693 patent/US8776216B2/en not_active Expired - Fee Related
- 2006-10-18 US US11/583,671 patent/US8688583B2/en active Active
- 2006-10-18 BR BRPI0617490-6A patent/BRPI0617490A2/pt not_active Application Discontinuation
- 2006-10-18 AP AP2008004453A patent/AP2008004453A0/xx unknown
- 2006-10-18 US US11/583,622 patent/US20070185815A1/en not_active Abandoned
- 2006-10-18 US US11/583,646 patent/US20070100768A1/en not_active Abandoned
- 2006-10-18 AU AU2006304655A patent/AU2006304655B2/en not_active Ceased
- 2006-10-18 CN CN201210218731.4A patent/CN102882677B/zh not_active Expired - Fee Related
- 2006-10-18 KR KR1020087011852A patent/KR101248296B1/ko not_active IP Right Cessation
-
2008
- 2008-04-17 IL IL190957A patent/IL190957A/en not_active IP Right Cessation
-
2012
- 2012-03-22 JP JP2012066252A patent/JP5357292B2/ja not_active Expired - Fee Related
Patent Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2003034408A2 (en) * | 2001-10-18 | 2003-04-24 | Nokia Corporation | System and method for controlled copying and moving of contents |
| WO2004008297A1 (en) * | 2002-07-11 | 2004-01-22 | University Of Wollongong | Methods for standard mechanisms for digital item manipulation and handling |
| WO2004027588A2 (en) * | 2002-09-23 | 2004-04-01 | Koninklijke Philips Electronics N.V. | Certificate based authorized domains |
| WO2004038568A2 (en) * | 2002-10-22 | 2004-05-06 | Koninklijke Philips Electronics N.V. | Method and device for authorizing content operations |
| WO2004059451A1 (en) * | 2002-12-30 | 2004-07-15 | Koninklijke Philips Electronics N.V. | Divided rights in authorized domain |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| RU2601146C2 (ru) * | 2011-08-10 | 2016-10-27 | Квэлкомм Инкорпорейтед | Основанная на уровне ослабления ассоциация в сетях связи |
| RU2722239C1 (ru) * | 2019-11-26 | 2020-05-28 | Общество с ограниченной ответственностью «ПИРФ» (ООО «ПИРФ») | Способ создания и использования формата исполняемого файла с динамическим расширяемым заголовком |
Also Published As
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| EA012918B1 (ru) | Системы и способы на основе механизма управления цифровыми правами | |
| US9626667B2 (en) | Digital rights management engine systems and methods | |
| AU2004200468B2 (en) | A method, system and computer-readable storage for a licensor to issue a digital license to a requestor | |
| AU2004200471B2 (en) | Publishing digital content within a defined universe such as an organization in accordance with a digital rights management (DRM) system | |
| CA2457291C (en) | Issuing a publisher use license off-line in a digital rights management (drm) system | |
| US20160224768A1 (en) | Digital Rights Management Engine Systems and Methods | |
| US20230086191A1 (en) | Systems and Methods for Token Content Unlocking, Biometric Authentication using Privacy-Protecting Tokens, Ownership-Based Limitations of Content Access, Policy-Based Time Capsule Technology, and Content Lock Mechanisms | |
| MX2008005060A (en) | Methods for digital rights management |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| MM4A | Lapse of a eurasian patent due to non-payment of renewal fees within the time limit in the following designated state(s) |
Designated state(s): AM AZ BY KZ KG MD TJ TM |
|
| MM4A | Lapse of a eurasian patent due to non-payment of renewal fees within the time limit in the following designated state(s) |
Designated state(s): RU |