WO2001041027A1 - Systeme et procede destines a la gestion securisee des droits numeriques electroniques et aux transactions et distribution de contenu securisees - Google Patents

Systeme et procede destines a la gestion securisee des droits numeriques electroniques et aux transactions et distribution de contenu securisees Download PDF

Info

Publication number
WO2001041027A1
WO2001041027A1 PCT/US2000/032892 US0032892W WO0141027A1 WO 2001041027 A1 WO2001041027 A1 WO 2001041027A1 US 0032892 W US0032892 W US 0032892W WO 0141027 A1 WO0141027 A1 WO 0141027A1
Authority
WO
WIPO (PCT)
Prior art keywords
content
user
license
secure
providing
Prior art date
Application number
PCT/US2000/032892
Other languages
English (en)
Other versions
WO2001041027B1 (fr
Inventor
Davor Runje
Mario Kovac
Josko Orsulic
Tomislav Uzelac
Brian D. Litman
Original Assignee
Davor Runje
Mario Kovac
Josko Orsulic
Tomislav Uzelac
Litman Brian D
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Davor Runje, Mario Kovac, Josko Orsulic, Tomislav Uzelac, Litman Brian D filed Critical Davor Runje
Priority to AU19438/01A priority Critical patent/AU1943801A/en
Publication of WO2001041027A1 publication Critical patent/WO2001041027A1/fr
Publication of WO2001041027B1 publication Critical patent/WO2001041027B1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/10—Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2211/00—Indexing scheme relating to details of data-processing equipment not covered by groups G06F3/00 - G06F13/00
    • G06F2211/007—Encryption, En-/decode, En-/decipher, En-/decypher, Scramble, (De-)compress
    • 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/2115—Third party
    • 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/2137—Time limited access, e.g. to a computer or data
    • 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/2153—Using hardware token as a secondary aspect

Definitions

  • This invention relates to systems and methods for rights management and efficient distribution of the content such as audio, video and other types of multimedia, electronic files, consumer electronic devices, and other. It also relates to systems for handling existing and future business and distribution models.
  • CD piracy Today, the music industry is suffering big financial losses because of CD piracy and rapidly increasing loss because of MP3 1 piracy. This is due to the low cost of copying CDs with a CD-R recorder and a computer. CDnow is the leading Internet music store in terms of total revenue. It was started in a founder's basement and had $6 million in sales in 1996. The biggest threat, however, comes from highly organized pirates that "press", distribute and sell illegal CDs. Individuals encoding their CDs and exchanging compressed music in MP3 format constitute a lesser threat than specialized sites with MP3 archives and search engines that provide unlimited access to anyone who has access to Internet.
  • 'MP3 is short for MPEG layer-3 standard. It is an audio compression algorithm standardized by ISO.
  • MP3 underground is a term for people that encode music from CDs and distribute it over the Internet. easily be sold in order make money from illegal activities. This results in MP3 sites being modestly maintained and with slow connection.
  • This invention enables content to be used or experienced by the end user only if an appropriate license has been previously obtained.
  • This invention allows existing distribution models to be directly mapped into the system and expanded by adding higher levels of functionality and usability.
  • the system consists of back-end entities that ensure proper operation of the system functions, and other nodes (such as content owners, distributors, etc).
  • the preferred embodiment of the system requires Secure Environment (SecEnv) and Secure Device (SecDev).
  • the system allows for several levels of security for both SecEnv and SecDev as defined in Security levels description.
  • Example Security levels that are defined in the system are: - non-secure software (SW) secured - (security built into SW package) level I: i..e. software contains certain IDs or crypto keys used for identification and/or encryption, decryption
  • SW secured level II - (hardware provides some identification information that is used by the SW) software reads IDs or crypto keys from the hardware device
  • Embedded level I - software is placed inside the embedded processor and this software contains certain IDs or crypto keys used for identification and/or encryption.decryption
  • Embedded level II - software is placed inside the embedded processor and software reads IDs or crypto keys from the protected storage inside the embedded processor
  • Secure chip level - software, IDs and keys are all stored within protected storage inside the embedded processor.
  • Execution environment is tamper proof (nothing can be read out, changed, etc.).
  • Example is a "Smartcard”.
  • SecEnv is defined as a secure and controlled environment (e.g. a secure computer in a secure building) where highly secure actions are performed and where the probability of illegal penetration is smaller then the one defined in the specified security level.
  • One example of SecEnv is the Secure Device personalization location.
  • the Secure Device personalization location is the production site where the KeyCards are personalized (specific IDs and keys are stored within them). This is a high-risk process that must be strictly controlled.
  • SecDev is similarly defined as a device that stores privileged data and/or performs privileged (secure) actions and where the probability that someone can illegally obtain privileged data and/or illegally perform a privileged action is smaller then the one defined in the specified security level.
  • a SecDev used in this invention is a Smart Card/Smart Chip device.
  • COs Content Owners
  • This invention allows for electronic and physical content (goods) or other content type (e.g. service).
  • Example content types can be defined as:
  • content could be: high quality audio, high/medium/low quality video, cable channel subscription, newspaper and many others.
  • Content Owners may (or may not) transform/modify the content before releasing it into the system. This transformation/modification can have several purposes one of which could be to protect the original content so that it cannot be experienced/used without the proper license from the Content Owner.
  • An example of this transform is compression, encryption and encoding of a digital audio file.
  • System Terminals are system nodes that act as an interface between users and the system. System Terminals enable transfer of data, content and/or licenses between system nodes and users. System terminals also allow browsing and searching of content offered by the system. Very simplified, one can see System Terminals as a combined retail store, ATM and search engine.
  • Content Reference Information about the content and content related identification
  • This reference can be stored in the "Shopping basket" of the License Management Device (LMD) to be used as a reference during license purchase activities or content retrieval activities.
  • LMD License Management Device
  • the preferred method for storing of this information to the LMD is e.g. a "Like" pushbutton on the consumer electronic device that extracts reference from stream being played or side channel and stores it in LMD.
  • Other approaches can also be used and have the same function.
  • a user Prior to purchase of the license, a user sends an offer request to the system.
  • the system replies by providing all possible offers (or selected offers based on predefined criteria) through which the license can be purchased.
  • Each offer represents a path from the content owner to the terminal.
  • the invention allows for free and dynamic creation of paths where each node (entity) can create it's own set of business models. By selecting one path (e.g. path with minimal price), the user initiates the license request process.
  • the license Upon execution of the transaction, the license is securely stored within License Management Device.
  • the Usage Device (UD) communicates with the License Management Device that controls if the content can be used or not.
  • the current invention allows for certain nodes to be merged together, if desired. For example, UD and LMD can be physically implemented as a single device.
  • a simplified example of usage of current invention is as follows.
  • Content Owner introduces new protected content, in this example a new song, to the system and markets it's existence on the radio.
  • a user listens the song while jogging and pushes the 'Like' button on his GSM phone/radio/music player so that information about the song is stored within the device.
  • the user After coming home, the user connects to the system network using his phone (the GSM service provider acts as a System Terminal) and obtains an offer response on the screen of his GSM phone.
  • the desired license for example an unlimited license
  • the system processes this transaction and returns the requested license to be stored on the License Management Device.
  • the user can now listen the song. In this case, since he purchased an unlimited license, he can listen to the song as many times as he wants.
  • FIG. 1 is a block diagram providing an overview of the system according to this invention.
  • Figure 2 is a block diagram illustrating system initialization.
  • Figure 3 is a block diagram illustrating system entity management.
  • Figure 4 is a block diagram illustrating system operation.
  • Figure 5 is a block diagram illustrating Certificate Authority creation.
  • Figure 6 is a block diagram illustrating Transaction Authority creation.
  • Figure 7 is a block diagram illustrating certificate generation
  • Figure 8 is a block diagram illustrating generation of a unique identification
  • Figure 9 is a block diagram illustrating generation of private and public keys
  • FIG 10 is a block diagram illustrating generation of Financial Clearance authority (FC)
  • Figure 11 is a block diagram illustrating Content Owner (CO) creation.
  • Figure 12 is a block diagram illustrating generation of a default business rule and insertion in the Business Rule Data Base (BRDB).
  • BRDB Business Rule Data Base
  • Figure 13 is a block diagram illustrating exposure source creation
  • Figure 14 is a block diagram illustrating usage device creation
  • Figure 15 is a block diagram illustrating distribution creation.
  • Figure 16 is a block diagram illustrating terminal creation
  • FIG 17 is a block diagram illustrating License Management Device (LMD) creation.
  • LMD License Management Device
  • Figure 18 is a block diagram illustrating content preparation.
  • Figure 19 is a block diagram illustrating generation of unique content identifier.
  • Figure 20 is a block diagram illustrating generation and storage of a FAT_HEADER.
  • Figure 21 is a block diagram illustrating content encoding.
  • Figure 22 is a block diagram illustrating content distribution flow.
  • Figure 23 is a block diagram i ustrating the content distribution process
  • Figure 24 is a block diagram i ustrating distributor content processing.
  • Figure 25 is a block diagram i ustrating adding a business rule into BRDB
  • Figure 26 is a block diagram i ustrating generation of the DIST_HEADER.
  • Figure 27 is a block diagram i ustrating exp. source content processing.
  • Figure 28 is a block diagram i ustrating generation of the EXPJHEADER.
  • Figure 29 is a block diagram i ustrating purchase of a licence.
  • Figure 30 is a block diagram i ustrating putting SHOPPINGJNFO into LMD.
  • Figure 31 is a block diagram i ustrating processing of SHOPPING_REQ
  • Figure 32 is a block diagram i ustrating requesting an offer
  • Figure 33 is a block diagram i ustrating TA processing of OFFER_REQ.
  • Figure 34 is a block diagram i ustrating Business Rule Data Base Manager
  • Figure 35 is a block diagram i ustrating generation of an offer
  • Figure 36 is a block diagram i ustrating user processing of OFFER_REQ.
  • Figure 37 is a block diagram i ustrating offer payment.
  • Figure 38 is a block diagram illustrating license retrieval.
  • Figure 39 is a block diagram illustrating license request creation
  • Figure 40 is a block diagram illustrating Transaction Authority processing of the license request.
  • Figure 41 is a block diagram illustrating Content Owner processing of LICENSE_REQ.
  • Figure 42 is a block diagram illustrating LMD processing of LICENSE_REQ.
  • Figure 43 is a block diagram illustrating content usage
  • Figure 44 is a block diagram illustrating LMD processing of USAGE_REQ.
  • Figure 45 is a block diagram illustrating LMD usage of content
  • Figure 46 is a block diagram illustrating licence management device - usage device communication requirements.
  • Figures 47-51 are examples of UDs that are enabled to utilize this system.
  • Figure 47 illustrates a combination CD player and radio (a "boom box").
  • Figure 48 illustrates a car radio
  • Figure 49 illustrates a GSM enabled phone.
  • Figure 50 illustrates a TV set with a remote control.
  • Figure 51 illustrates a set top TV control box, as would be used with cable or satellite TV, with a remote control.
  • This invention is an integrated, modular, fully interchangeable globally scalable e- commerce architecture for the secure and trusted connection of buyers (individuals) and sellers (e.g record companies, artists, movie studios) of digital content (e.g. music, videos).
  • secure digital content can be distributed via traditional CD and made accessible to the user via inexpensive authorization systems akin to the credit card swipers found at merchants worldwide.
  • the owners of the copyrights can take their libraries and compile, decompile, make albums and collections, discount and bundle, giveaway or otherwise create every conceivable commercial usage of their digital assets.
  • copyright holders are able to licence rights to end-users based on specific and time-based "permissions" which define when and how the end- user will enjoy the content in question.
  • the ability for copyright owners to fully control usage of their copyrights and the fact that they never cede ownership is key to this invention's attractiveness.
  • AAC Advanced Audio Codec
  • STS Secure Transaction Server
  • the STS monitors each transaction on the network.
  • the STS is a trusted third party system. Therefore it will likely involve the participation of another party to audit and verify compliance such as one of the major accounting firms.
  • a KeyCard containing digital licenses Preferably, it is the size of a credit card but with a microchip inside.
  • a user When a user registers with the system for the first time, they will receive in the mail (or at a checkout counter) their KeyCard. To activate their key, the user inserts it into a special terminal and inputs a PIN. The user always keeps they key with them.
  • the KeyCard is embedded with next-generation "digital cash" or dollar credits that the user can use to pay for new licenses.
  • B. A storage medium containing encrypted and watermarked content. The content files are secured using near military-grade cryptography.
  • One storage medium is smart media or memory cards which are removable and interchangeable with any playback device compatible with this invention.
  • Another storage medium is CDs or higher density DVDs.
  • a portable or fixed-position playback device A portable or fixed-position playback device.
  • the KeyCard contains all of the information that the system needs to know about the user. With the KeyCard users will be able to search the entire database of available content that they can be issued to rights to enjoy on the network.
  • This database will be a combination of the respective databases maintained by the owners of the copyrighted material in question. Since the database is based on a common database structure, all of the content that the copyright holders wish to make available will be searchable.
  • the database is housed at the Secure Transaction Server Center.
  • the KeyCard is based upon term and conditional access or "permission sets".
  • the KeyCard recognizes what content each registrant is eligible to experience. For example, if the content is a song, the KeyCard knows, song by song, how many times the user can listen to that song. If the user purchased the song for 100 listens, then with each play of the song, the software incrementally decreases the permitted experiences. Each time a song that was previously licensed is utilized, the KeyCard remembers exactly what song was listened to and uploads this data each time the user's account is accessed using the KeyCard. If the user purchased unlimited listens, then they have just that. Users can recharge their keys, swap licenses, etc.
  • the storage device may contain the entire Beatles catalog, but the user, may wish only purchase permissions to access the tracks of "The White Album" for the time being. But at any point in the future, the user could add or delete their permissions to access all of those Beatles tracks with the appropriate payment.
  • the KeyCard will also hold digital cash and could likely have a dual GSM cellphone function. This fits with predictions of unified portable devices that are PDA's, cellphones and music players all-in-one.
  • Devices compatible with this invention include components consumers are already accustomed to. Home stereos, portable players, e-books and car radios.
  • this invention uniquely adds the following: PC's, cable and satellite TV, hotel and cruise ship in-room systems, airline and bus in-seat entertainment consoles and even next-generation cellphones.
  • this invention can be engineered to allow, on a track by track basis, whether or not that particular track can be played back on the PC in CD-quality or if playback may only occur in secure mode via a compatible portable or fixed playback device.
  • This invention also provides for a downloadable content playing application.
  • the content player will have a built in application application which allows invention users to send the low quality sample files via e-mail.
  • This invention has been specifically designed to integrate into next-generation TV, set-top boxes. This invention will allow cable and satellite TV to deeply participate in secure content distribution via high-speed modems or traditional VBI technologies.
  • FIG. 1 shows an embodiment of the present invention 5 in block diagram form.
  • This system 5 includes three basic processes: initialization of basic system components 10, management of other system entities 11 and operation of the system 12.
  • FIG. 2 provides a closer look at system initialization 10.
  • Certificate Authority CA
  • Transaction Authority TA
  • Auxiliary support entities of Business Rule Database Manager (BRDBMGR) 16 and Business Rule Database (BRDB) 15 itself are also created during system initialization.
  • Shown in FIG. 3 is the process of creation of other system entities: Financial Clearance authority (FC) 17, Content Owner (CO) 18, Exposure Source (EXP) 19, Usage Device (UD) 20, Distributor (DIST) 21 , Terminal (TERM) 22 and License Management Device (LMD) 23.
  • the Exposure Source exposes users to content through digital or analog subchannel by means of physical distribution (CDs), broadcast, streaming or download of integral content of reference to content (DISTJHEADER).
  • FIG. 4 shows system operation 12 divided into several sub processes: preparation of content 24, distribution of prepared content 25, purchase of user licenses 26 and finally usage of licensed content 27.
  • FIG. 9 shows the process of generating two pairs of asymmetric keys within SecEnv.
  • a pair of keys is generated 39 for chosen digital signature algorithm such as DSS, RSA, ECC or other.
  • a pair of keys, DecKeyCard and EncKeyCard is generated 41 for chosen public key encryption algorithm such as EIGamal, RSA, ECC or other.
  • EIGamal public key encryption algorithm
  • Two kinds of public key algorithms are used: a) Digital signature algorithms. These attach a piece of additional digital data (signature) to an original document that links this document and person that signs it. Two keys are generated: one for signing digital data (called signature key, abbreviation SigKey) and one for verification of that signature (verifying key, abbreviation VerKey). In the key generation process, both keys are generated in the same time. VerKeyCard is public, because its purpose is to allow anyone to verify signature. SigKeyCard is private so only its holder can sign data.
  • Two private keys SigKey and DecKey must be stored within entity's SecDev and should not be known to other system nodes.
  • Two public keys VerKey and EncKey are made available to other system nodes.
  • SigKey, VerKey, DecKey and EncKey are private signing keys, public verifying key, private decrypting key and public encrypting key.
  • a prefix like CA, CO, etc. means that appropriate key belongs to CA, CO, etc.
  • Certificate Authority is the primary system entity and it is created within SecEnv (see Figure 5).
  • the first pair of keys is CASigKey and CAVerKey. These keys are used during the later process of creation of other system nodes and serve the purpose of certification and verification of identity of these nodes.
  • Second pair of keys, CADecKey and CAEncKey is generated for chosen public key encryption algorithm such as EIGamal, RSA, ECC or other. It is used for public key encryption and together with the first key pair is used to establish and ensure secure communication connection/secure communication channel between CA and other system nodes. If certain algorithms such as RSA are used, signature and encryption key pairs may be shared.
  • Two private keys CASigKey and CADecKey must be stored within CA SecDev and should not be known to other system nodes.
  • Two public keys CAVerKey and CAEncKey must be present in all other system nodes.
  • CA creation process 13 ends with the creation of self signed CA certificate 29.
  • This certificate is self-signed because CA is the top-level authority used for certification of identities of other system entities.
  • Every system entity has a unique identifier within its entity type, and the process of its generation is described in FIG 8. Again, within SecEnv, a unique identifier (e.g. pseudo random number) is created 36. With the help of CA, the uniqueness of this identifier for each given entity type is verified 37, 38.
  • a unique identifier e.g. pseudo random number
  • entity certificate is created 34(see Figure 7).
  • the certificate of every system entity consists of: entity type identifier, entity identifier, verification key, encryption key and entity's security level. This data structure is then forwarded (in secure fashion) to the CA, and the process of certificate generation 30 is completed after the CA signs the certificate 35. All certificates are made available to other system entities.
  • Transaction authority (TA) entity is created 14 within SecEnv. See Figure 6.
  • an entity certificate is generated 30, as described previously.
  • TAJNFO data structure is added 31 to the entity database. This structure consists of entity certificate, its network address and possibly other relevant information.
  • FC entity Financial clearance authority (FC) entity is created 17 within SecEnv. See Figure 10.
  • entity certificate is generated 30, as described previously.
  • FCJNFO data structure is added 42 to the entity database. This structure consists of entity certificate, its network address, business information (such as bank account numbers) and possibly other relevant information.
  • CO Content owner entity
  • An entity certificate is generated 30, as described previously.
  • the default Business Rule of this particular content owner is generated 43.
  • the content owner creates 45 this Business Rule in accordance with its business policy, and forwards it 46, 47 (see Figure 12) to the Business Rule Database Manager (BRDM) for verification and insertion into the Business Rule Database (BRD).
  • BRDM Business Rule Database Manager
  • COJNFO data structure is added 44 to the Entity Database (ED).
  • This structure consists of the entity certificate, its network address, business information (such as bank account numbers) and possibly other relevant information.
  • Exposure source (EXP) entity is created 21 within SecEnv. See Figure 13.
  • an entity certificate is generated 30, as described previously.
  • EXPJNFO data structure is added 48 to the Entity Database. This structure consists of the entity certificate, its network address, business information (such as bank account numbers) and possibly other relevant information.
  • UD entity is created 20 within SecEnv. See Figure 14.
  • an entity certificate is generated 30, as described previously.
  • UDJNFO data structure is added 49 to the entity database. This structure consists of the entity certificate, its manufacturer information and possibly other relevant information.
  • DIST Distributor
  • entity is created 21 within SecEnv. See Figure 15.
  • an entity certificate is generated 30, as described previously.
  • DISTJNFO data structure is added 50 to the entity database.
  • This structure consists of entity certificate, its network address, business information (such as bank account numbers) and possibly other relevant information.
  • Terminal (TERM) entity is created 22 within SecEnv. See Figure 16.
  • an entity certificate is generated 30, as described previously.
  • TERMJNFO data structure is added 51 to the entity database.
  • This structure consists of entity certificate, its network address, business information (such as bank account numbers) and possibly other relevant information.
  • LMD Creation (23)
  • License Management Device (LMD) entity is created 23 within SecEnv. See Figure 17.
  • an entity certificate is generated 30, as described previously.
  • LMDJNFO data structure is added 52 to the entity database. This structure consists of the entity certificate, its manufacturer information and possibly other relevant information.
  • CO Content Owner
  • CO generates 53 a unique content identifier, for later identification of this particular content by other system entities.
  • CO chooses a unique Content ID for this particular Content Owner (in random or some other fashion) and verifies 62 its availability. If available 63 this Content ID is allocated 64 for use and marked unavailable (in Business Rule Database). See Figure 19.
  • the next step is the generation of FATJHEADER 54, a data structure containing information about content that is later embedded into the encoded content.
  • the generation process is performed in several stages.
  • the Content owner generates the FAT_HEADER structure and signs 65 it with COSigKey, thus creating a self signed FAT_HEADER structure consisting of Content Owner Identifier and Content Identifier. These identifications uniquely define every content available to the system. See Figure 20.
  • FAT_HEADER is now sent to Transaction authority (TA) for processing 66.
  • TA retrieves 67 COJNFO from the entity database and checks 68 to see if this Content Owner is revoked. If not, CO signature on FATJHEADER is verified 69. In case of revoked CO, TA sends a reject message. If a valid signature of non-revoked CO is found, TA signs FATJHEADER and sends 70 it back to CO, together with TA's signature.
  • TA now creates 71 CONTENTJNFO data structure consisting of FATJHEADER and content description. Reference to this content is added 71 to the DISABLED table in the BRDB.
  • DISABLED table is a list of all content that is created and encoded but is not for sale yet because appropriate business rules are not defined yet. Its main purpose is to avoid race condition where content owner creates FATJHEADER for new content, thereby allowing other distributors to locate that content, but business rules for that content are not created until next step. Making the content publicly available (58 in Figure 18) creates the appropriate business rule if needed (if not, default business rule would apply) and removes content from DISABLED table.
  • CO After having received the TA signed FATJHEADER, CO performs preprocessing of content, if needed 55, 59. Encoding of content is the next step 56, 60, also optional. This process is performed in order to protect digital content with encryption. CO generates 72 random CONT_KEY used for encryption of content and stores 73 it with reference to appropriate CONTJD into local, protected storage. Content data is then encrypted 74 and merged with FAT header to form an encoded digital content. See Figure 21.
  • CONT_KEY For content encryption, standard private key encryption is used. One key (called CONT_KEY) is used to encrypt content. The very same key is needed to decrypt content. That key is uniquely identified with two IDs: COJD that identifies content owner and CONTJD that identifies particular content of CO. There can not be two CONT_KEYs with the same CONTJD from the same CO (COJD).
  • DISTJHEADER data structure can be generated 83 containing information about the distributor that is later on embedded into the encoded content.
  • the generation process is performed in several stages.
  • the distributor generates DISTJHEADER structure and signs 88 it with DistSigKey, thus creating a self signed DISTJHEADER structure consisting of Content Owner Identifier, Content Identifier and Distributor Identifier.
  • DISTJHEADER is now sent to Transaction authority (TA) for processing 89.
  • TA retrieves 90 DIST INFO from the entity database and checks 91 if this Distributor is revoked. If not, the distributor signature on DIST_HEADER is verified 92. In case of a revoked distributor, TA sends a reject message.
  • TA checks 93 for consistency with BRDB and, if found consistent, signs 94 DISTJHEADER and sends 94 it back to Distributor, together with TA's signature.
  • Distributor now can merge 84 DISTJHEADER with content to be distributed. See Figure 26.
  • This process of sub distribution is repeated 78 if more sub distribution channels are acceptable with a given business policy.
  • Exposure Source processing is the next link 79 in the chain of content distribution.
  • Exposure Source processing 80 of content is performed. See Figure 27. Exposure Source processes content in accordance with it's own, content owner's and sub distributors' business policies. If a special business rule is needed 95, Exposure Source acts together with the TA, and adds 82 it to the database, after having it created 85, and accepted 86, 87 by the TA. See Figure 25.
  • EXPJHEADER data structure can be generated 96 containing information about Exposure Source that is later on embedded into the encoded content. The generation process is performed in several stages as shown on Figure 28. First, Exposure Source generates EXPJHEADER structure and signs 98 it with ExpSigKey, thus creating a self signed EXPJHEADER structure consisting of Content Owner Identifier, Content Identifier and Exposure Source identifier. EXPJHEADER is now sent to Transaction authority (TA) for processing 99. TA retrieves 100 EXP JNFO from the entity database and checks 101 if this Exposure Source is revoked. If not, Exposure Source signature on EXPJHEADER is verified 102.
  • TA Transaction authority
  • TA In case of a revoked Exposure Source, TA sends a reject message. If a valid signature of a non-revoked Exposure source is found, TA checks 103 for consistency with BRDB and if found consistent signs 104 EXP_HEADER and sends 104 it back to Exposure Source, together with TA's signature. Exposure Source now can merge 97 EXPJHEADER with content to be exposed. After performing all necessary steps, content is made 81 publicly available. The process of content distribution is summarized in Figure 22.
  • the process of license purchase begins with a user selecting content she wants and putting 105 its SHOPPINGJNFO data structure into LMD's storage. See Figure 29.
  • Content references can be obtained by different means: browsing or querying local content databases on Terminal 109, screening of Content by Usage device or Terminal 110 or screening of some side-channel by LMD enabled device 111. See Figure 30.
  • user selects desired content 112 and Terminal, Usage Device or LMD enabled device, creates SHOPPING_REQ and sends 113 it to the License Management Device.
  • LMD then processes 114 this SHOPPING_REQ. This is done by first unpacking 115 it and then verifying 116 the signature part of FATJHEADER.
  • an offer request is made 106 by LMD on behalf of the user.
  • LMD prepares 123 data structures. These structures are then sent 124 to the Transaction Authority.
  • TA now processes 125 each OFFER_REQ.
  • the first step is retrieving 127 LMD JNFO from the entity database. Then the TA checks 128 to see if that LMD is revoked. If found revoked, an abort message is sent but if LMD is not revoked, LMD signature on OFFER_REQ is checked 129. If this signature is invalid, again an abort message is sent. If valid signature is found, TA forwards 130 OFFER_REQ to Business Rule Database Manager for further processing and waits 131 for OFFER_RES response from BRDB Manager. See Figures 32 and 33.
  • the Business Rule Database Manager checks for existence 133 of Content Owner Identifier and for existence 134 of Content Identifier. If any of these identifiers does not exist, an abort message is sent. If checks 133 and 134 are successful, BRDB Manager checks to see if Content is disabled 135. Again, if disabled, an abort message is sent. If selected Content is not disabled, applicable value chains are found 136 in the Business Rule Database. If there are valid value chains 137, OFFERs are generated 138 for every value chain. In case there are no valid chains, an abort message is sent. All generated OFFERs are packed 139 into OFFER J ES and sent to Transaction Authority. See Figure 34.
  • OFFER_REQ is a request that the user (that is LMD) creates when he/she wants to acquire CONT_KEY for protected content (CONT_KEY is needed to decrypt content). It consists of unique identifier of content (COJD and CONTJD) and some additional data that describe the way user is accessing content (DISTJD and EXPJD) and the way user is accessing system service (TERMJD). OFFER_REQ is LMD specific and therefore, LMDJD is also included. LICENSE_TYPE field describes what kind of license (CONT_KEY + usage rights) user wishes to (e.g. time limited, number of playbacks, unlimited, etc.). LMDJD is a unique identifier of License Management Device (e.g. smartcard).
  • the LMD creates that OFFER_REQ.
  • the OFFER generation sub process begins with generation 140 of unique OFFERJD. Identifiers from OFFER_REQ (Content owner, Content, Distributor, Exposure Source, Terminal and License Management Device identifiers) are then stored 141 under this reference, together with Value Chain 142. From this Value Chain, price and expiration date are calculated 143, and the OFFER structure is created 144. See Figure 35.
  • OFFER is data structure that is obtained as result of BRDB query for license and applicable business rules of previously described OFFER REQ . It contains all data from OFFER_REQ and some additional data like price.
  • OFFER_RES is list of OFFERs. After having received OFFER_RES, Transaction Authority signs 132 each OFFER from OFFER_RES and sends it back to the License Management Device. Further processing 126 of OFFER J ES has to be done as shown in Figure 36.
  • the first step is for the Terminal to verify 145 TA signatures of all OFFERs contained in OFFER_RES. If all signatures are valid 146, Terminal displays 147 OFFERs to the user and prompts for selection and/or approval. If invalid signatures are found, Terminal informs 148 user about invalid OFFER RES. If user has selected 149 some OFFERs, Terminal sends 150 them to the License Management Device. LMD then checks 151 Transaction Authority signatures on all received OFFERs. If all signatures are valid 152, OFFERs are stored 153 to the License management device.
  • Offer payment is the next step 107 in the license purchase process.
  • the user selects 154 one or more OFFERs stored on the License Management Device.
  • the user initiates 155 payments with Financial Clearance authority (FC) for selected OFFERs and waits 156 for response. If payment was successful 157 LMD marks references matching paid OFFERs 158 for license retrieval. FC notifies Transaction Authority that the financial transaction was successful and TA forwards this information to the Business Rule Database Manager. If there are more OFFERs to be processed 159, the whole payment process is repeated.
  • FC Financial Clearance authority
  • License retrieval follows 108 offer payment. If there are references marked for retrieval 160, License Management Device creates 161 LICENSE J EQ, using generated and stored 167 random nonce 3 and encodes and signs 168 the created LICENSEJ EQ. That data structure is then sent 162 to the Transaction authority for processing 163.
  • TA retrieves 169 LMDJNFO structure from the entity database and checks 170 if LMDJNFO exists. If not, a LICENSE_REJECT message is sent 171 to LMD. If LMDJNFO exists, License Management Device signature is checked 172 on the LICENSE_REQ data structure. If the signature is found invalid, another LICENSE J EJECT message is sent 173 to LMD. If License management device signature is valid, Business Rule Database Manager is queried 174 for the OFFER referred to in the LICENSEJ EQ. If this OFFER exists 175, LMDJD is valid and the offer is paid for, Transaction Authority retrieves 177 COJNFO from entity database. If any of these conditions is not true, a further LICENSE_REJECT message is sent 176 to LMD. See Figure 40.
  • Random nonce is a random (or pseudo random) number that is used in many cryptographic protocols.
  • Transaction Authority sends 178 LICENSE J EQ, OFFER and LMDJNFO structures to the Content Owner.
  • CO now processes LICENSE_REQ by first encrypting 180 the CONTENT_KEY with LMD public encryption key (LMDEncKey) retrieved from LMDJNFO.
  • LMD public encryption key (LMDEncKey) retrieved from LMDJNFO.
  • USAGEJ IGHTS are then copied 181 from the OFFER and LICENSE J ES is created and sent 182 back to the Transaction Authority.
  • LMDEncKey is public encryption key of LMD.
  • USAGE_RIGHTS is e.g. right to playback content 10 times, or right to playback content for 10 days, or right to transfer content from one LMD to another, etc. See Figure 41.
  • License Management Device after waiting 164 for response from TA, depending 165 on the type of response continues the process. If response was LICENSE REJECT, further processing is canceled and retrieval of next license is started. Ifthetype of TA response was LICENSE J ES, LMD processes 166 this response. First, Transaction authority signature is checked 183, and matching LICENSE EQ is searched 184 for. (In this context matching means that identifiers and stored nonce value should be the same in LICENSE_REQ and LICENSE_RES.) If matching LICENSEJ EQ is found, CONTENT_KEY is decrypted 185 using LMDDecKey and stored 186 together with Usage Rights. LICENSE_REQ for now retrieved license is deleted 187. See Figure 42. LMDDecKey is private decryption key of LMD.
  • Content usage (FIG. 43) is the central part 27 of the current invention's operation. The user first needs to initiate this process by requesting playback or other forms of content usage. Then, one of the key establishment protocols (e.g. X.509 Secure Authentication Protocol 4 ) is executed 188 between Usage Device and License
  • 4 X.509 Secure Authentication Protocol is cryptographic protocol usedto establish secure, authenticated connection over an insecure channel between two parties.
  • Management Device This protocol is used to establish COM_KEY, a symmetric encryption key used for securing of the communication between LMD and UD.
  • Usage Device now identifies 189 content to be used and sends 190 USAGE J EQ to LMD for given content in a secure fashion. After receiving it, License Management Device processes 191 said USAGE_REQ by first extracting 196 Content owner and Content Identifiers. LMD now looks 197 for referenced content license in the license storage. If requested license is not found 198, License Management Device sends 203 a USAGE_REJECT message to the Usage Device.
  • USAGE J IGHTS are checked 199 and if usage of said content is not allowed, again, a USAGE_REJECT message is sent 204 to the Usage Device. If stored USAGE J IGHTS allow use of content, the Rights are updated 200 if necessary and a USAGE_PERMIT message is created 201 , optionally containing a CONTENT_KEY. License Management Device now sends 202 a USAGE_PERMIT massage to the Usage Device. See Figures 43 and 44.
  • UD Random number generator in UD can be replaced with non-volatile counter. Requirement on UD RNG is generation of non-repeating values only. The values do not need to be unpredictable and have any statistical properties.
  • LMD Certificate Certificate containing LMD public keys used for digital signature verification and public key encryption, signed by CA - RNG - Random number generator. It must be cryptographically strong and is used for generation of session keys used to encrypt sensitive information.
  • FIGS 47-51 Examples of system-compatible devices are shown in Figures 47-51. Only audio and video devices are illustrated on Figures 47-51. Those familiar with the art to which this invention pertains will realize that the technology of this invention can be extrapolated to other forms of digital content.
  • Each device illustrated on Figures 47-51 includes a KeyCard slot 250 and a "Like” button 260 or equivalent.
  • Devices with remote controls 265 have an additional "Like" button 260 on the remote 265.
  • content information is transmitted together with the audio/video data.
  • Content information can be transmitted by RDS (as the simplest method already available) or sideband technologies. If the device includes any type of display some text info about the content (e.g. artist and title) can also be presented to the listener/viewer. If the listener/viewer likes the content he/she can instantly memorize it for future purchase by simply pressing 'Like' pushbutton. All other necessary actions (storing this information on the KeyCard) are performed automatically by the system.
  • the device features a slot for a storage medium and the storage medium is inserted, the device stores content information to a "shopping basket" on the storage medium. If the storage medium is not inserted content information is stored internally. When the storage medium is next inserted, all memorized information in the shopping basket is transmitted to storage medium.
  • the device does not feature a slot for a storage medium, minimum system requirements are that it has special 'Like' pushbutton (or emulates this function by combination of existing pushbuttons) and that it has some NV internal memory. After 'Like' pushbutton is pressed content information is stored to internal memory. The user can later transmit this data to other system compatible devices by means of IR transmission, cable connection, DTMF signaling, or similar method.
  • the receiver device can be a slot with a storage device or another device featuring a storage device or another device capable of memorizing content information.

Abstract

L'invention concerne un système (5) et un procédé destinés à la gestion des droits électroniques, à la gestion des transactions et à la distribution du contenu sécurisées. Le système (5) fait en sorte que l'utilisateur final ne peut utiliser ou accéder au contenu que s'il est en possession d'une licence appropriée. Les propriétaires du contenu préparent le contenu qui doit être placé dans le système (5) et le mettent à disposition sous forme électronique ou physique. Avant d'acheter la licence, l'utilisateur envoie au système (5) une demande d'offre. Le système (5) répond en lui proposant toutes les offres disponibles (ou les offres sélectionnées, basées sur des critères prédéfinis) qui permettent d'acquérir la licence. Chaque offre représente une voie depuis le propriétaire du contenu jusqu'au terminal. En sélectionnant une voie, l'utilisateur lance le processus de requête de licence. Après exécution de la transaction, la licence est stockée de façon sécurisée dans le dispositif personnel de gestion de licence de l'utilisateur. Le dispositif personnel d'utilisation communique avec le dispositif de gestion de licence de l'utilisateur; de cette manière, l'utilisation n'est possible qu'en rapport avec un contenu sous licence.
PCT/US2000/032892 1999-12-03 2000-12-01 Systeme et procede destines a la gestion securisee des droits numeriques electroniques et aux transactions et distribution de contenu securisees WO2001041027A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU19438/01A AU1943801A (en) 1999-12-03 2000-12-01 System and method for secure electronic digital rights management, secure transaction management and content distribution

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US16898399P 1999-12-03 1999-12-03
US60/168,983 1999-12-03

Publications (2)

Publication Number Publication Date
WO2001041027A1 true WO2001041027A1 (fr) 2001-06-07
WO2001041027B1 WO2001041027B1 (fr) 2001-11-15

Family

ID=22613804

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2000/032892 WO2001041027A1 (fr) 1999-12-03 2000-12-01 Systeme et procede destines a la gestion securisee des droits numeriques electroniques et aux transactions et distribution de contenu securisees

Country Status (2)

Country Link
AU (1) AU1943801A (fr)
WO (1) WO2001041027A1 (fr)

Cited By (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2362229A (en) * 2000-04-07 2001-11-14 Sony Uk Ltd Provision of copyrighted media items
EP1335266A1 (fr) * 2002-02-12 2003-08-13 Vodafone Group PLC Procédé et système de répartition et de gestion pour des terminaux mobiles des droits d utilisation associés à l'achat du contenu
WO2004070538A2 (fr) * 2003-02-03 2004-08-19 Tennessee Pacific Group, L.L.C. Distribution et gestion des droits de contenus numeriques
GB2399208A (en) * 2003-03-07 2004-09-08 Marius Kahan Downloading and paying for data files using a smart card
EP1480103A2 (fr) * 2003-05-22 2004-11-24 Sharp Kabushiki Kaisha Système de protection de contenu numérique contre son utilisation non autorisée
EP1508865A1 (fr) * 2002-05-29 2005-02-23 Sony Corporation Systeme de traitement d'informations
WO2005086103A1 (fr) * 2004-02-27 2005-09-15 Koninklijke Kpn N.V. Tickets multiples pour contenu de reception
JP2008530653A (ja) * 2005-02-08 2008-08-07 コンテントガード ホールディングズ インコーポレイテッド 将来的に作成されるディジタル・コンテンツに対する使用権を確立するための方法及び装置
US7890428B2 (en) 2005-02-04 2011-02-15 Microsoft Corporation Flexible licensing architecture for licensing digital application
US8091142B2 (en) 2005-04-26 2012-01-03 Microsoft Corporation Supplementary trust model for software licensing/commercial digital distribution policy

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5666412A (en) * 1994-10-03 1997-09-09 News Datacom Ltd. Secure access systems and methods utilizing two access cards
US5677955A (en) * 1995-04-07 1997-10-14 Financial Services Technology Consortium Electronic funds transfer instruments
US5991402A (en) * 1997-09-23 1999-11-23 Aegisoft Corporation Method and system of dynamic transformation of encrypted material

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5666412A (en) * 1994-10-03 1997-09-09 News Datacom Ltd. Secure access systems and methods utilizing two access cards
US5677955A (en) * 1995-04-07 1997-10-14 Financial Services Technology Consortium Electronic funds transfer instruments
US5991402A (en) * 1997-09-23 1999-11-23 Aegisoft Corporation Method and system of dynamic transformation of encrypted material

Cited By (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2362229A (en) * 2000-04-07 2001-11-14 Sony Uk Ltd Provision of copyrighted media items
EP1335266A1 (fr) * 2002-02-12 2003-08-13 Vodafone Group PLC Procédé et système de répartition et de gestion pour des terminaux mobiles des droits d utilisation associés à l'achat du contenu
ES2198201A1 (es) * 2002-02-12 2004-01-16 Airtel Movil S A Procedimiento y sistema de distribucion y gestion de derechos de uso asociados a un contenido adquirido, para terminales moviles.
EP1508865A4 (fr) * 2002-05-29 2006-06-07 Sony Corp Systeme de traitement d'informations
US8601277B2 (en) 2002-05-29 2013-12-03 Sony Corporation Information processing system
US8909935B2 (en) 2002-05-29 2014-12-09 Sony Corporation Information processing system
US10521624B2 (en) 2002-05-29 2019-12-31 Sony Corporation Object device including an IC chip
EP1508865A1 (fr) * 2002-05-29 2005-02-23 Sony Corporation Systeme de traitement d'informations
US9858456B2 (en) 2002-05-29 2018-01-02 Sony Corporation Information processing system
WO2004070538A2 (fr) * 2003-02-03 2004-08-19 Tennessee Pacific Group, L.L.C. Distribution et gestion des droits de contenus numeriques
WO2004070538A3 (fr) * 2003-02-03 2005-02-10 Tennessee Pacific Group L L C Distribution et gestion des droits de contenus numeriques
EA009793B1 (ru) * 2003-02-03 2008-04-28 ТЕННЕССИ ПАСИФИК ГРУП, Эл. Эл. Си. Распространение и управление правами для цифрового контента
GB2399208A (en) * 2003-03-07 2004-09-08 Marius Kahan Downloading and paying for data files using a smart card
EP1480103A3 (fr) * 2003-05-22 2006-08-30 Sharp Kabushiki Kaisha Système de protection de contenu numérique contre son utilisation non autorisée
US7412601B2 (en) 2003-05-22 2008-08-12 Sharp Kabushiki Kaisha Illegal data use prevention system
EP1480103A2 (fr) * 2003-05-22 2004-11-24 Sharp Kabushiki Kaisha Système de protection de contenu numérique contre son utilisation non autorisée
WO2005086103A1 (fr) * 2004-02-27 2005-09-15 Koninklijke Kpn N.V. Tickets multiples pour contenu de reception
US7890428B2 (en) 2005-02-04 2011-02-15 Microsoft Corporation Flexible licensing architecture for licensing digital application
JP2008530653A (ja) * 2005-02-08 2008-08-07 コンテントガード ホールディングズ インコーポレイテッド 将来的に作成されるディジタル・コンテンツに対する使用権を確立するための方法及び装置
US8091142B2 (en) 2005-04-26 2012-01-03 Microsoft Corporation Supplementary trust model for software licensing/commercial digital distribution policy

Also Published As

Publication number Publication date
AU1943801A (en) 2001-06-12
WO2001041027B1 (fr) 2001-11-15

Similar Documents

Publication Publication Date Title
US20010032312A1 (en) System and method for secure electronic digital rights management, secure transaction management and content distribution
US7124304B2 (en) Receiving device for securely storing a content item, and playback device
US8244639B2 (en) Content identification, personal domain, copyright notification, metadata and e-Commerce
US8095578B2 (en) Data processing system and method therefor
US7096504B1 (en) Distribution system, semiconductor memory card, receiving apparatus, computer-readable recording medium and receiving method
EP1678569B1 (fr) Unite de gestion de droits d'utilisation electronique pour un systeme de gestion de droits d'utilisation electronique
US20050021783A1 (en) Information processing apparatus and method
US20020062290A1 (en) Method for distributing and licensing digital media
US20030101142A1 (en) Information recording apparatus, information reproducing apparatus, and information distribution system
EP1272948A1 (fr) Systeme de commerce electronique sur
CN104077501B (zh) 可互操作的密钥箱
JPH10207755A (ja) データベースへの暗号化情報の転送方法およびその装置、ならびに認証モジュールおよびパーソナリティモジュール
AU2008283770A2 (en) Method and apparatus for distributing digital content
WO2006001161A1 (fr) Procédé de traitement de support de stockage, appareil de traitement de support de stockage, et programme
JP2005503719A (ja) ディジタルドキュメントの安全な配信方法とシステム
JP4987978B2 (ja) デジタルフィンガープリンティングを用いたデジタルコンテンツ供給システム
WO2001041027A1 (fr) Systeme et procede destines a la gestion securisee des droits numeriques electroniques et aux transactions et distribution de contenu securisees
JP2003298565A (ja) コンテンツ配信システム
JP2003152700A (ja) 情報端末装置およびコンテンツ復号方法
JP3578101B2 (ja) コンテンツ提供方法及び装置及びコンテンツ提供プログラム及びコンテンツ提供プログラムを格納した記憶媒体
ABEDIN REFERENCE TO RELATED APPLICATIONS
WO2001024080A1 (fr) Lecteur securise pour donnees de reproduction

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

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

AL Designated countries for regional patents

Kind code of ref document: A1

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

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

Kind code of ref document: B1

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

AL Designated countries for regional patents

Kind code of ref document: B1

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

B Later publication of amended claims
REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

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

Ref country code: JP