US20140123220A1 - BUSINESS METHOD INCLUDING CHALLENGE-RESPONSE SYSTEM TO SECURELY AUTHENTICATE SOFTWARE APPLICATION PROGRAM INTERFACES (APIs) - Google Patents

BUSINESS METHOD INCLUDING CHALLENGE-RESPONSE SYSTEM TO SECURELY AUTHENTICATE SOFTWARE APPLICATION PROGRAM INTERFACES (APIs) Download PDF

Info

Publication number
US20140123220A1
US20140123220A1 US14/066,591 US201314066591A US2014123220A1 US 20140123220 A1 US20140123220 A1 US 20140123220A1 US 201314066591 A US201314066591 A US 201314066591A US 2014123220 A1 US2014123220 A1 US 2014123220A1
Authority
US
United States
Prior art keywords
claimant
verifier
hook
challenge
response
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Abandoned
Application number
US14/066,591
Other languages
English (en)
Inventor
Eric J. Sprunk
Mark G. DePietro
Alexander Medvinsky
Paul Moroney
Xin Qiu
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Arris Technology Inc
Original Assignee
General Instrument Corp
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
Priority to BR112015009690A priority Critical patent/BR112015009690A8/pt
Application filed by General Instrument Corp filed Critical General Instrument Corp
Priority to US14/066,591 priority patent/US20140123220A1/en
Priority to MX2015005454A priority patent/MX355757B/es
Priority to PCT/US2013/067353 priority patent/WO2014070800A1/en
Priority to AU2013338059A priority patent/AU2013338059B2/en
Priority to KR1020157014437A priority patent/KR101722868B1/ko
Priority to CA2899385A priority patent/CA2899385C/en
Assigned to GENERAL INSTRUMENT CORPORATION reassignment GENERAL INSTRUMENT CORPORATION ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: SPRUNK, ERIC J., MORONEY, PAUL, DEPIETRO, MARK G., MEDVINSKY, ALEXANDER, QIU, XIN
Publication of US20140123220A1 publication Critical patent/US20140123220A1/en
Assigned to ARRIS TECHNOLOGY, INC. reassignment ARRIS TECHNOLOGY, INC. MERGER AND CHANGE OF NAME (SEE DOCUMENT FOR DETAILS). Assignors: GENERAL INSTRUMENT CORPORATION
Assigned to BANK OF AMERICA, N.A., AS ADMINISTRATIVE AGENT reassignment BANK OF AMERICA, N.A., AS ADMINISTRATIVE AGENT SECURITY INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: ARCHIE U.S. HOLDINGS LLC, ARCHIE U.S. MERGER LLC, ARRIS ENTERPRISES, INC., ARRIS GLOBAL SERVICES, INC., ARRIS GROUP, INC., ARRIS HOLDINGS CORP. OF ILLINOIS, INC., ARRIS INTERNATIONAL LIMITED, ARRIS SOLUTIONS, INC., ARRIS TECHNOLOGY, INC., BIG BAND NETWORKS, INC., GIC INTERNATIONAL CAPITAL LLC, GIC INTERNATIONAL HOLDCO LLC, JERROLD DC RADIO, INC., NEXTLEVEL SYSTEMS (PUERTO RICO), INC., POWER GUARD, INC., TEXSCAN CORPORATION
Assigned to GIC INTERNATIONAL HOLDCO LLC, NEXTLEVEL SYSTEMS (PUERTO RICO), INC., ARRIS GLOBAL SERVICES, INC., ARRIS HOLDINGS CORP. OF ILLINOIS, INC., GIC INTERNATIONAL CAPITAL LLC, BIG BAND NETWORKS, INC., ARCHIE U.S. HOLDINGS LLC, ARRIS SOLUTIONS, INC., ARRIS GROUP, INC., ARRIS TECHNOLOGY, INC., TEXSCAN CORPORATION, ARRIS INTERNATIONAL LIMITED, ARCHIE U.S. MERGER LLC, ARRIS ENTERPRISES, INC., POWER GUARD, INC., JERROLD DC RADIO, INC. reassignment GIC INTERNATIONAL HOLDCO LLC TERMINATION AND RELEASE OF SECURITY INTEREST IN PATENTS Assignors: BANK OF AMERICA, N.A., AS ADMINISTRATIVE AGENT
Abandoned legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/235—Processing of additional data, e.g. scrambling of additional data or processing content descriptors
    • H04N21/2351—Processing of additional data, e.g. scrambling of additional data or processing content descriptors involving encryption of additional data
    • 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
    • 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/105—Arrangements for software license management or administration, e.g. for managing licenses at corporate level
    • 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/12—Protecting executable software
    • G06F21/121—Restricting unauthorised execution of programs
    • 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/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
    • 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
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/629—Protecting access to data via a platform, e.g. using keys or access control rules to features or functions of an application
    • 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/126—Applying verification of the received information the source of the received data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/435—Processing of additional data, e.g. decrypting of additional data, reconstructing software from modules extracted from the transport stream
    • H04N21/4353—Processing of additional data, e.g. decrypting of additional data, reconstructing software from modules extracted from the transport stream involving decryption of additional data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/443—OS processes, e.g. booting an STB, implementing a Java virtual machine in an STB or power management in an STB
    • H04N21/4431—OS processes, e.g. booting an STB, implementing a Java virtual machine in an STB or power management in an STB characterized by the use of Application Program Interface [API] libraries
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/443—OS processes, e.g. booting an STB, implementing a Java virtual machine in an STB or power management in an STB
    • H04N21/4433—Implementing client middleware, e.g. Multimedia Home Platform [MHP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/647—Control signaling between network components and server or clients; Network processes for video distribution between server and clients, e.g. controlling the quality of the video stream, by dropping packets, protecting content from unauthorised alteration within the network, monitoring of network load, bridging between two different networks, e.g. between IP and wireless
    • H04N21/64715—Protecting content from unauthorized alteration within the network

Definitions

  • the present invention relates to secure authentication of access to software capabilities through Application Program Interfaces (APIs).
  • APIs Application Program Interfaces
  • the present invention relates to the use of a regime to enable software API usage and authentication using a concept known as Hook IP.
  • Hook IP provides a way often to enable access to some patented technology, often as part of a trust establishment mechanism. This means that anyone wanting to implement a software function or API such as Digital Rights Management (DRM) must do so in a way that will be covered by certain “Hook IP” patents. A condition of obtaining such a Hook IP license is to follow the terms of the license relating to the patents as well as other Intellectual Property (IP) such as potential trade secrets and copyrights.
  • IP Intellectual Property
  • DVD Digital Video Broadcast
  • ETSI European Television Standards Institute
  • CAS conditional access system
  • Hook IP in the past has been defined to mean using patents or other technological Intellectual Property (IP) in a licensing scheme where the Hook IP is being used in conjunction with encryption of media content (e.g. video or audio or data) for transfer protection.
  • IP Intellectual Property
  • the system was covered by two patents covering a Common Scrambling Algorithm (CSA) encryption algorithm to efficiently encrypt video streams.
  • the system source was a cable headend or satellite uplink that provided media content through a cable, satellite, or terrestrial signal path to a receiver set top box.
  • CSA Common Scrambling Algorithm
  • DVD-CCA Digital Video Disk Copy Control Association
  • SCS Content Scrambling System
  • DTLA Digital Transmission Licensing Administrator
  • ECC Elliptic Curve Cryptography
  • PKI Public Key Infrastructure
  • DLNA Digital Living Network Alliance
  • TCP Transmission Control Protocol/Internet Protocol
  • CPRM Content Protection for Recordable Media Entity dated from about 1999.
  • the system covers a Cryptomeria Cipher and a facsimile key that were used to encrypt content on media.
  • the system operated using removable media, such as an SD card.
  • DCP Digital Content Protection
  • HDCP High-Bandwidth
  • HDMI High-Definition Multimedia Interface
  • CMLA Content Management License Administrator
  • AACS Advanced Access Content System
  • Ecosystem is used here to mean a set of business, technology, and licensing interrelationships that work together for mutual benefit.
  • an Ecosystem may or may not include Hook IP, our use herein comprises only Ecosystems that contain Hook IP.
  • the “ founders” of the ecosystem usually have a joint interest in creating and maintaining the ecosystem stability.
  • the term “Founders” is used because the Ecosystem operators typically are early entrants to the Ecosystem, or entities that otherwise aggressively compete in the Ecosystem.
  • a “Licensing Entity” can be formed by a pooling of resources of the founders to form a narrow-purpose “Licensing Entity” that will administer and police the ecosystem they wish to create.
  • the Founders, and by their direction the Licensing Entity usually have a list of controls or ecosystem rules that they wish to obligate or impose upon all Actor participants in the ecosystem they govern, their goal being facilitation of a stable ecosystem that is mutually beneficial to all participants. Going forward, the Licensing Entity will be referenced herein as a proxy for the Founders.
  • Controls imposed by the Licensing Entity include both (1) business controls and (2) technical controls.
  • the business controls (1) can include intellectual property (IP) ownership, or other legal restrictions that can result in liability, 3 rd party damages or consequential damages for improper behavior.
  • IP ownership can also be used to grant the rights to practice the Licensing Entity solutions as judged by the Licensing Entity, i.e. another business control.
  • the final business control follows the ability of granting rights in that it gives the ability to bar or exclude a party from bad behavior as deemed appropriate by the Licensing Entity.
  • Technical controls (2) include important Ecosystem-wide implementation “robustness rules” of the system to prevent a technical attack, such as deciphering encoding or having IP rights that can be avoided, without which the Ecosystem may lose its fundamental viability.
  • the technical rules also include “compliance rules” that might include technology design rules that Actor devices or software must comply with under terms of a licensing agreement.
  • the business controls outweigh technical controls in the use of Hook IP.
  • the Hook IP technology is really a side show to these business objectives and, along with careful use of Hook IP, the business obligations enables enforcement of the Hook IP system as described later in this document.
  • Problem1 is the secure transfer problem, or the need to provide encryption necessary to protect some Asset. Encryption is based on establishing mutual trust in the decrypters and encrypters.
  • the “Licensing Entity” is often a standards body like Digital Video Broadcast (DVB) or an industry consortium standards body like CableLabs or Digital Video Disk Copy Control Association (DVD-CCA) that have the technical “Problem1” to be solved.
  • DVD-CCA Digital Video Disk Copy Control Association
  • the Licensing Entity has controls that they wish to obligate or impose upon participants.
  • the Licensing Entity seeks a means of forcing the controls onto all ecosystem participants in a fully-binding, legally licensed manner, with enforcement provided in case of misbehavior.
  • the role of Hook IP in this situation is not necessarily to prevent bad actors or rogue implementations per se, but to create a patent infringement enforcement means should a rogue implementation be discovered by the Licensing Entity.
  • Problem1 has four different technical solutions, possibly using either Existing Patent Technology (EPT) and/or “Potentially Patentable Technology” (PPT). Depending on how much (if any) of EPT or PPT is used, different degrees of business IP protection are achieved. Details of the business protection provided by Solution1-Solution4 to Problem1 are described to follow.
  • EPT Existing Patent Technology
  • PPT Potentially Patentable Technology
  • Solution1 uses technology that is covered by expired patents, i.e. neither EPT or PPT.
  • a Licensing Entity choosing to use Solution1 can only use Trade Secret or Copyright rights as the contractual consideration for its grants to Licensees.
  • Trade Secrets can, however, be legally overcome by a party's reverse engineering, which nullifies their enforcement.
  • Copyrights can also be legally circumvented through independent software recoding to intentionally avoid the copyrighted material and nullify the value of copyright material as an enforcement entity.
  • the Solution1 regime without patent rights for enforcement, has very little survivability in a competitive world, and can be substantially ineffective in protecting the Asset.
  • Solution2 does not use any Existing Patented Technology (EPT), but may contain Potentially Patentable Technology (PPT) or sufficient inventive matter to apply for a patent with an unknown chance of future grant.
  • EPT Existing Patented Technology
  • PPT Potentially Patentable Technology
  • Solution2 has the characteristics of Solution1 above, and is less effective in protecting the Asset.
  • Solution3 uses Existing Patented Technology (EPT). For a Licensing Entity choosing to use Solution3, the EPT is immediately available to enforce Solution3 through patent licensing. There is no delay or uncertainty associated with a pending patent application. The enforcement utility of EPT, however, is confined to the grant period before the patents expire.
  • EPT Patented Technology
  • Solution3 has the negative characteristics of Solution1 above, or worse since some copyright or trade secret protection may remain in Solution1, and it will be ineffective in protecting the Asset the Licensing Entity seeks.
  • Solution3 can therefore have a short useful lifespan. A very short lifespan, for example of one or two years remaining, would make Solution3 pointless from the perspective of the Licensing Entity's enforcement goals.
  • Solution4 uses a mix of EPT and PPT.
  • EPT is immediately available to enforce patent licensing, without the delay or uncertainty associated with a pending patent application.
  • the initial enforcement utility of EPT is confined to the lifespan of its patent(s), which may be long or short.
  • the PPT patent application filing timing should, then, be controlled so that it issues as a patent prior to expiration of the EPT. A few years overlap may be needed to allow reasonable prosecution time in the patent office.
  • the desire is to file the PPT as late as possible, however, to extend the lifespan of the PPT as long as possible following the EPT. Given an average lifespan of EPT of 8-12 years and the filing of PPT at that same time, the total period of enforcement for Licensing Entity could fall in the range of 28-32 years.
  • Solution4 typically will provide the best protection for a Licensing Entity if patent enforcement is available.
  • Solution3 provides the next best protection with patents involved.
  • Solution2 is highly speculative and has limited confident business control for the Licensing Entity until the PPT grant.
  • Solution1 offers minimal utility with no patent protection available.
  • the source and destination physical devices were connected by a channel, the nature of each element in the system varied.
  • the source varied from being 1000's of miles away from the destination with e.g. a DVB implementation to a few inches away e.g. in systems such as a DVD CCA or CPRM.
  • the source provided a trusted point where encryption took place.
  • the channel was not trusted, and could be a radio signal over the air or a long wire, or digital bits recorded on a storage device.
  • the destination provided a trusted place for decryption where the content was either stored or used by being displayed to a user.
  • FIG. 1 illustrates the source-channel-destination system described for previous Hook IP systems.
  • the source 100 provides the asset through encryption when the source has signed a Hook IP license agreement.
  • the destination 102 then decrypts the asset when the destination has signed a Hook IP license agreement and provides the decrypted asset for use. As shown, the encryption and decryption are tightly coupled to the Hook IP license.
  • the prior art Hook IP situation described above can be summarized as a set of business goals that leverage the technical solution to Problem1 to force licensees to agree to a list of terms and conditions dictated by a Licensing Entity in a way that allows assertion of patent or other IP for enforcement of technology constraints and prevention of use of the technology by unauthorized parties. Licensees as well as rogue implementers were required to use the Hook IP because of the inherent nature of encryption in the system that employed the Hook IP.
  • the Hook IP basically “rode along” with the encryption protection in a mandatory. To the extent that the chosen encryption is reasonably strong and cannot be circumvented, a party had to access encryption secrets to get the valuable content. Hook IP added to the encryption protection to further control and provide business protection over the content. Without this intertwining between encryption and Hook IP, the scheme collapsed.
  • embodiments of the present invention solve the problem of how to achieve the business goals of the Hook IP Ecosystem described above, but in a situation where there is no content encryption to base Hook IP upon. In other words, the problem to be solved is not Problem1.
  • a further problem that embodiments of the present invention solves is how to provide a system where software is being used, typically through an API, that does not involve predetermined hardware devices, for instance when the software is being used with or within a computing cloud.
  • Embodiments of the present invention provide a system that can solve the above described problems.
  • the new system also provides benefits of previous Hook IP Regimes including Compliance and Robustness Rules, Liability Obligations, etc.
  • the new system can further still be enforceable using a patented system, such as used in a prior art Hook IP implementations.
  • a new Hook IP system can include both existing patent technology as well as future patented technology, as described in Solution4 above.
  • a system of embodiments of the present invention that can accomplish this includes a new handshake protocol that will employ Hook IP.
  • the system is further provided in a generalized Hook IP ecosystem that includes: (1) A Licensing Entity; (2) Actors A 1 , A 2 , etc.; (3) Business Obligations imposed on Actors; and (4) Functions F 1 , F 2 . . . that are implemented by the Actors.
  • the Licensing Entity controls access to patent rights of Hook IP, and is responsible for imposing business rules upon the ecosystem.
  • the Actors are the desired participants within the ecosystem and operate hardware or software products that the Licensing Entity desires to control.
  • the Obligations imposed by the Licensing Entity will include the patent rights or other IP rights.
  • the Functions are implemented by the Actors to enable the Handshaking to occur.
  • Embodiments of the present invention include a handshake protocol that is provided to validate whether the parties involved are Licensed to use the Hook IP.
  • the Handshake is one of several Challenge/Response protocols, and includes the following steps.
  • a Claimant sends a request to a Verifier requesting access to transmit data through an API.
  • the Claimant and Verifier can be an arbitrary data storage components such as cloud storage, or they can be more specific devices such as a cable system set-top-box, middleware or a CAS.
  • the Verifier reacts to the request by outputting a Challenge that is sent to the Claimant.
  • the Challenge is also retained by the Verifier for use in its internal calculation to verify the Claimant's response.
  • the Claimant next processes the Challenge using Hook IP and issues a Response that is transmitted back to the Verifier.
  • the Verifier compares the possibly-correct Candidate Response from the Claimant to the known-correct Target Response it originally calculated using the Retained Challenge, and if a match occurs the Verifier allows the Claimant access to the API.
  • FIG. 1 diagrams a prior art system with a Hook IP License used to access software from a source to a destination;
  • FIG. 2 shows an ecosystem according to the present invention with a handshake procedure provided in order to authenticate a software between a Claimant and a Verifier;
  • FIG. 3 illustrates how a Hook IP Licensing Regime can be pulled through from an Alpha Actor to a Beta Actor;
  • FIG. 4 illustrates how a single first Hook IP Licensing Regime can be pulled through multiple actors including an Alpha, Beta and Gamma Actor;
  • FIG. 5 provides a more concise symbology equivalent to FIG. 4 ;
  • FIG. 6 uses the symbology of FIG. 5 to show a more complex license regime than FIG. 5 ;
  • FIG. 7 shows in table form the Actors, Functions and Hook IP for the FIG. 6 Ecosystem.
  • FIG. 8 illustrates components of an example ecosystem with components from a cable system.
  • a system of embodiment of the present invention that can accomplish this includes a new handshake protocol that will employ Hook IP.
  • the system is further provided in a generalized Hook IP ecosystem that includes:
  • a Licensing Entity that controls access to patent rights to Hook IP, and is responsible for imposing business rules upon all ecosystem participants.
  • Actors A 1 , A 2 . . . who desire to be participants within the ecosystem. Actors are entities that wish to engage in commerce within that ecosystem by offering products or services that would need access the Hook IP patent rights.
  • the Licensing Entity will want all Actors to sign up as Licensees to be able to use Hook IP and enforce all necessary business rules.
  • Functions F 1 , F 2 . . . that exist within the system and are implemented by the Actor(s).
  • the functions can be implemented in hardware, e.g. an MPEG decompression chip.
  • the functions could also be implemented in software, e.g. Conditional Access System (CAS) software running on a set top box as delivered through a middleware API.
  • CAS Conditional Access System
  • the Handshake is provided to validate whether the parties involved are Licensed to use the Hook IP.
  • the Handshake is one of several Challenge/Response protocols, and includes the following steps.
  • a Claimant begins the Handshake by sending a request to a Verifier.
  • the Claimant by sending the request will be essentially claiming to be a member of the Licensing Regime by beginning the Handshake protocol.
  • the Verifier reacts to the request by outputting a Challenge that is sent to the Claimant.
  • the challenge is also retained by the Verifier for use in its internal calculation to verify the Claimant's response.
  • the Challenge retained is processed using Hook IP and Administrative Info to create a Target Response that is held in memory of the Verifier to validate the reply from the Claimant.
  • the Admin Info can contain one or more of a unique ID, unique name, or the Claimant name.
  • the Admin Info can be either transferred to the Claimant as part of the Challenge, or is already provided to the Claimant based on their notification as a Licensee.
  • the Target response prepared by the Verifier for verification is not accessible by the Claimant and will be later proven based on the Claimant's response to the Challenge to indicate that the Claimant is licensed to use the Hook IP and also possesses the Admin Info.
  • the Claimant next processes the Challenge using Hook IP and issues a Response that is transmitted back to the Verifier.
  • the Claimant uses the Admin Info, Challenge and Hook IP to process and create the Candidate Response.
  • the Candidate Response equals the Target Response, it has been proven that the Claimant possesses the Hook IP and Admin Info correctly.
  • the Verifier compares the possibly-correct Candidate Response from the Claimant to the known-correct Target Response it originally calculated using the Retained Challenge.
  • the strength of the Verifier's conclusion that the Claimant is a member of the Licensing Regime depends upon the following string of interlocked components: (a) The extent that the Candidate Response cannot be created without the Hook IP and Admin Info; (b) The extent the Hook IP technology used is difficult to circumvent or avoid; (c) The extent the Hook IP employs a cryptographic one way or one way trap door function that allows further maximization of the Candidate Response strength.
  • Said function could comprise a keyed has using algorithms such as Secure Hash Algorithms (SHA), or an asymmetric digital signature such as RSA, Digital Signature Algorithm (DSA), El Gamal or Elliptic Curve DSA (ECDSA).
  • SHA Secure Hash Algorithms
  • DSA Digital Signature Algorithm
  • EDSA El Gamal or Elliptic Curve DSA
  • the Verifier during the comparison can determine if the Candidate Response is (1) identical to the Target response or (2) not identical to the Target response. If the Target response is (1) identical to the Candidate Response, the Verifier knows that both the Claimant and Verifier possess the same Hook IP and Admin Info. The verifier cannot tell if the Claimant illegally possess the Hook IP. If the Claimant's possession is illegal and unlicensed, however, and the Claimant proceeds it will be committing patent infringement of any underlying patented technology. With the Target response being identical, whether the Claimant is licensed or not, the Verifier will begin performing its function to enable the requesting Claimant access through its interface or API.
  • Target Response is (2) not identical
  • the Verifier considers the Claimant to be not trusted and declines to perform the Verifier's function to allow the Claimant access through its interface or API. Without the identical Target and Candidate responses, the Claimant is assumed to not have the correct Hook IP, and to not be a member of the Licensing Entity's Regime.
  • the system in some embodiments allows the Verifier to tell a difference between multiple Claimants, some of whom may have passed the Handshake Protocol and some who may have failed.
  • the Verifier can notify the Licensing Entity of the Claimant's failed Handshake if such a process is enabled by the specific embodiment. This will enable Patent Infringement enforcement against any party later discovered to have practiced the Hook IP without being a member in good standing in the Licensing Regime. Note that with this basic system it is not possible for either the Claimant or Verifier to directly know if the other party is a validly licensed participant in the Licensing Regime.
  • the Verifier will need to request the Licensing contractual status of the Claimant in a process separate from Handshaking This is desirable since it can potentially catch Patent Infringing parties early, which is of interest to the Licensing Entity who is charged with enforcing the Licensing Regime on the ecosystem. Other data is typically needed to do this, e.g. a reliable Claimant identification means wherein the Licensed Verifier can query a presumably remote Licensing Entity regarding Claimant's License status.
  • the Licensing verification can also include a security means to resist Rogue Claimants from falsifying a response to the Licensing Entity.
  • a variation of this invention is where the Handshake Protocol is also used to establish a Shared Secret Value possessed by both Claimant and Verifier.
  • Said Shared Secret Value can be used as an encryption key or cryptographic component in the establishment of encryption, or as an authenticator for use by Claimant and/or Verifier in API transactions after successful completion of the Handshake Protocol.
  • Further variation of this invention include where post-Handshake API calls are authenticated using said Shared Secret Key, or are completely encrypted by it.
  • FIG. 2 is a diagram illustrating the Claimant-Verifier Handshaking process.
  • the system shows the Claimant 200 and the Verifier 210 .
  • the Claimant 200 and Verifier 210 each include a processor and memory storing code to cause the processor to comply with the handshake process.
  • Internal components of the Claimant 200 and Verifier 210 illustrate code modules that enable the handshaking
  • the Claimant 200 initially generates a request 202 that is sent to block 212 of Verifier 210 that will in turn generate the Challenge that is sent to the Claimant 200 .
  • the challenge generator module 204 of the Claimant 200 then generates a response that has information relating to Hook IP for which it has rights under a signed license.
  • the module 204 further provides data for a function F needed for the Challenge, including Admin Info 206 that is stored in memory 206 for the Challenge.
  • the Verifier in step 216 compares in module 214 the Challenge with a Target Response it has generated.
  • the Target Response was created in module 214 when the Verifier originally created the Challenge using Hook IP license information that is needed with the Challenge to ensure the Claimant 200 has rights under Hook IP.
  • the comparator module 214 outputs a determination if a match is detected, and modules 218 and 220 provide a function depending on whether a match has occurred so that module 222 can provide an appropriate response back to the Claimant 200 .
  • the system architecture includes a set-top box or similar device, an operating system and middleware, and applications that run on top the middleware that provide content for the set-top box access, the applications potentially residing in cloud memory devices.
  • the set top device includes a System on a Chip (SoC) which performs decryption of the digital content. Encrypted keys are supplied by software stored in ROM to the SoC of the set top. All application programs accessed by the set top device run on top of the middleware. Access to the applications by the set top box or other local hardware resources is done by API calls to the middleware.
  • SoC System on a Chip
  • a variety of services to the user include the CAS Client which is responsible for obtaining authorizations and cryptographic keys (in encrypted form) for decrypting and accessing the digital content (e.g., video and audio).
  • the CAS client After determining that a particular device is authorized for a particular multimedia service, the CAS client will forward encrypted keys to the hardware via API calls to the middleware layer. As a result, the SoC hardware of the set top will begin decryption, decompression and rendering of the digital content.
  • a “Challenge-Response” API mechanism is provided between the CAS client and middleware to ensure secure authentication of the CAS Client API.
  • the CAS in a first example system, rather than middleware, controls the “Challenge.” That procedure begins after the user tunes the set-top to a particular channel.
  • the middleware then submits a request for CAS support in order to decrypt the content corresponding to the desired channel.
  • the CAS App returns back the “Challenge” which can be either a random number of a non-repeating numerical value that had not been previously used by the CAS.
  • the middleware responds by calculating a function over the Challenge value, where that function is patented and referred to herein as Hook IP.
  • the CAS App then verifies the response from the middleware and returns an acknowledgement that the CAS services have been enabled.
  • the CA App After the CA App has granted access to CA APIs, it proceeds to provide encrypted keys for use by the SoC by making the corresponding API calls to the Middleware.
  • the system provides secure control of all of the applications and middleware that are running in a device separate from the encryption and decryption keys.
  • an application or Middleware provider has to first sign a business agreement and obtain the secret Hook IP algorithm for the Challenge/Response.
  • the flow of APIs is reversed and it is the middleware that issues the “Challenge.”
  • the procedure begins after the user tunes a set-top-box to a particular channel.
  • the CAS submits a request for the middleware to access content decryption APIs that will be used by the CAS to load decryption keys.
  • the middleware returns back the “Challenge” which can be either a random number of a non-repeating numerical value.
  • the CAS responds by calculating a function over the Challenge value, where that function is patented Hook IP.
  • the middleware verifies the response from the CAS and returns an acknowledgement that decryption APIs have been enabled.
  • the middleware also returns the “API Handle” that the CAS may subsequently pass to the middleware in order to prove that it has been authorized.
  • the content for the channel to be delivered in either example case can come from a cable headend, and content keys are also delivered by the cable headend to the CAS.
  • the CAS then passes the content decryption keys that came from the headend and are themselves encrypted to the SoC of the set-top-box via the middleware. Because the Hook IP based authorization has succeeded with the challenge-response scenario, the middleware will pass the encrypted keys to the SoC with the API handle. A user of the set top box can then view the decrypted content on the channel.
  • the Response includes an App-Class along with the Challenge calculated in a function “F( ) as follows:
  • the function F( ) includes both the “Challenge” and the Class of Application that all access different sets of APIs.
  • an application has to be aware of secret parameters that are associated with a specific APP-Class.
  • CAS Applications are given one set of secret parameters, applications with access to user private data have a different set of secret parameters.
  • the application provider will sign a business agreement for a specific APP-Class and in return will obtain the corresponding secret parameters and will be able to compute the Response.
  • System C In a further variation is a system termed “System C,” where in addition to performing a challenge-response for a specific class of applications, the middleware has to check permissions or restrictions for a specific device.
  • instances of the same class of applications may have access to different APIs within different physical devices.
  • the middleware In addition to performing challenge-response and identifying a specific class of applications, the middleware has to check permissions or restrictions for a specific device. This additional device check may require a request to an external service outside of the middleware to look up authorizations from an object or a file from an external server.
  • the Administrative Info can be retained to create the Target Response that is held in memory of the Verifier to validate the reply from the Claimant that includes more than just a randomly generated number.
  • the Admin Info can contain one or more of a unique ID, unique name, or the Claimant name. The Admin Info can be either transferred to the Claimant as part of the Challenge, or is already provided to the Claimant based on their notification as a Licensee.
  • the system can further add to the Admin Info by requiring the assignment of non-transitory identifiers or personalities to software instantiations, giving a piece of software a unique and distinct identify similar to how a serial number labels a physical object.
  • the Response to a Challenge can be a Function that includes an App-Class.
  • an application provider that will be accessible through an API can sign a business agreement for a specific APP-Class and in return will obtain the corresponding secret parameters to enable them to compute the Response.
  • a subsequent encryption can be provided of the data, even though the data was not encrypted prior to the Challenge-Response. Encryption after the Challenge-Response will enable more efficient operation, as after the Challenge-Response, when more data is requested over the API another Challenge-Response scenario is not required as the encryption will signify that a Challenge-Response procedure has already occurred and that the Claimant has a license that is verified under Hook-IP.
  • an ecosystem of entities including Functions and Actors all controlled under a common Licensing Regime can be constructed. This is done through making the Hook IP mandatory for the set of desirable functions F 1 , F 2 , . . . in the Ecosystem, where the Ecosystem Actors that Licensing Entity wishes to control are motivated by their desire to access these functions F 1 , F 2 . . . in some way.
  • Actors A 1 and A 2 may require a single function F 1 or a number of separate functions F 1 and F 2 .
  • two Actors A 1 and A 2 may each have different functions F 1 and F 2 , each of which is viewed as necessary and valuable to the other.
  • a 1 may act as the Verifier for F 1 with A 2 as Claimant
  • a 2 may act as Verifier for F 2 with A 1 as Claimant.
  • the party that needs some function F expresses their need through the Handshake Claimant role to another party that has that function F, who expresses their ability to satisfy a need for F through their role as a Handshake Verifier.
  • the ecosystem for embodiments of the present invention hinges upon an interaction between different Actors that seek to use each other's function(s) F.
  • the Handshake occurs when the software or device of one Claimant Actor asks for another Verifier Actor's software or device to perform a function F for it. If there is only one Actor, this situation cannot be satisfied and a degenerate case results. It is meaningless for a single Actor A 1 to perform a Handshake with itself using Hook IP. A single Actor case is thus degenerate and will not work, so this case will not be focused upon further. Put colloquially, if a single Actor owns everything, there is never a need for him to ask himself for permission for anything.
  • the Licensing Entity control multiple Actors that need to access a single function F 1 .
  • This is achieved by beginning with a license agreement imposed upon an Actor A 1 that owns or implements F 1 .
  • the desirability of F 1 then transfers the Licensing Regime to all other indirect users of F 1 , thereby spreading the Licensing Regime.
  • Actor A 1 implements F 1 ; other users of F 1 use F 1 indirectly by asking A 1 to operation function F 1 for them through the Handshake Protocol, typically through an interface or API, where the requester acts as a Handshake Claimant and Actor A 1 acts as the Handshake Verifier.
  • Alpha Actor that is the very first to sign up to the Licensing Regime.
  • the Alpha Actor will design their software or device to require the Handshake and Hook IP to perform its function F 1 for other “Beta Actor” devices or software.
  • This first Alpha Actor essentially boot straps the Licensing Regime by being first and using the Hook IP Handshake as a condition of Beta Actor access to F 1 . All subsequent Beta Actors that implement software or devices that interface to said first Alpha Actor must therefore use this same Hook IP and Handshake, and must sign up to the Licensing Regime to legally do so.
  • FIG. 3 illustrates the ability of Beta Actors to be pulled in to requiring Hook IP based on their need for a function such as F 1 from an Alpha Actor.
  • the interfacing Alpha Actor in the ecosystem will create a marketplace force that pushes other Beta Actors to likewise submit to the Licensing Regime.
  • FIG. 3 includes an Alpha Actor 300 that may be the Verifier as in FIG. 2 , as well as a Beta Actor 302 that may be the Claimant in FIG. 2 .
  • the Alpha Actor 300 controls Hook IP 1 licensing rights for function F 1 .
  • the Beta Actor 302 has a business desire for function F 1 that pulls it into signing a license for Hook IP 1 so that access can be made for the business desired.
  • the Beta Actor 302 further controls other functions F 2 , F 3 . . . that are separate from F 1 .
  • the functions F 2 and F 3 can then be pulled into the ecosystem that can further the license Hook IP 1 , or create their own separate Licenses for Hook IP 2 and Hook IP 3 , etc.
  • Hook IP can be introduced in parallel all at one time into the ecosystem with one or more of the functions F 1 , F 2 . . . and Actors A 1 , A 2 . So long as all Actors are agreeable to directly signing up to the Licensing Regime, there may be no necessity to indirectly force them. In that case, it is not necessary for there to be an Alpha Actor to create marketplace interoperability pressure on Beta Actors.
  • Such a cooperative, conflict-free ecosystem where IP licensees willingly sign up and pay royalties for a technology license is, however, unlikely to occur in a competitive world.
  • the Ecosystem has one function F 1 and one or more Alpha Actors, and this used as follows to promulgate the Licensing Regime beyond just the Alpha Actors to Beta and Gamma Actors.
  • F 1 is implemented in one Alpha Actor device or piece of software, where F 1 will not operate until the Handshake is completed and Hook IP confirmed present in a Beta Actor that requests F 1 .
  • the steps to propagate the license are as follows:
  • the Licensing Regime is signed up to by all Alpha Actors that wish to implement or own F 1 .
  • the Alpha Actor's license from the Licensing Entity obligates it to only offer F 1 over an API that uses licensed Hook IP and a Handshake.
  • the Licensing Regime is “pulled through” (or imposed) upon all Beta Actors that wish to use F 1 though said Al interface or API for F 1 .
  • Beta Actors licensed thereunder to require the successful completion of the Handshake Protocol before that Beta Actor will perform another function F 2 for another “Gamma” Actor requesting F 2 through A 2 's API.
  • a like means can promulgate the Licensing Regime forward through F 2 , F 3 , etc. to an arbitrary number of functions and Actors.
  • FIG. 4 shows this concept extends ad infinitum from Alpha Actors 400 to Beta Actors 402 , to Gamma Actors 404 , etc.
  • the Beta Actor 402 would be pulled into the ecosystem by their wanting to be users of the F 1 functions implemented by the Alpha Actor 400 .
  • the Gamma Actors would be pulled in via their desire to use the F 2 functions of the Beta Actors, etc.
  • the same Hook IP 1 License will be used for each to increase the ecosystem.
  • Arbitrarily complex ecosystems can be subjected to a Licensing Regime in this way.
  • FIG. 5 shows a compression of the symbology of FIG. 4 to enable further illustration more complex scenarios in future figures.
  • the symbology in FIG. 5 shows the same scenario as FIG. 4 with components 500 , 502 and 504 of FIG. 5 replacing the more detailed symbols 400 , 402 and 404 of FIG. 4 .
  • FIG. 5 better illustrates a subsequent Actor's need coming into that Actor from the right, labeled numerically in accordance with the function that can satisfy that need.
  • Function F 1 is needed in Need N 1 , etc.
  • the provision of a function F goes out from the Actor symbol to the left. Functions of one Actor thus connect to needs of another Actor.
  • the Licensing Regime 510 is labeled “F0” to denote its instigating role in the ecosystem, and correspondingly Alpha Actor A 1 's need for Hook IP 1 (HIP 1 ) is numbered “N0”.
  • FIG. 6 illustrates where an Actor can have multiple needs (connecting from the left) and multiple functions (connecting from the right).
  • FIG. 6 uses the concise symbology of FIG. 5 to illustrate a more complex ecosystem and the use of multiple types of Hook IP (“HIP”) HIP 1 - 9 instead of a single Hook IP License HIP 1 to spread a single Licensing Regime through an ecosystem of 6 Actors A 1 -A 6 , as labeled 601 - 606 respectively.
  • HIP Hook IP
  • each Actor in Al-A 6 may act as a Handshake Verifier (or enforcer) for one function it implements and offers to other Actors through an API, and also be a Handshake Claimant for another function that it needs through a different API.
  • a given Actor in A 1 -A 6 can further be a Verifier for a function it owns and a Claimant for other functions that other Actors own. It can be seen that the current invention extends naturally to arbitrarily complex scenarios involving software from different Actors offering functions through APIs to many other Actors, whether on different computing platforms, or a single platform, or a cloud implementation of platforms.
  • the system of FIG. 6 might be a complexity worst case scenario. It could be even more complex, however, if different types of Hook IP were used in different “directions”, i.e. when A 1 wants F 2 from A 2 , HIPX is used, but when A 2 wants F 1 from A 1 , HIPY is used.
  • HIPX when A 1 wants F 2 from A 2 , HIPX is used, but when A 2 wants F 1 from A 1 , HIPY is used.
  • each of the 6 Actors A 1 -A 6 labeled 601 - 606 has its own valuable function(s) F 1 -F 6 which are the economic benefit and purpose for their being in the ecosystem at all.
  • Some Actors have more than one function, e.g. Actor A 1 has F 1 A and F 1 B.
  • the functions of some Actors may be used by multiple other Actors, e.g. Actor A 3 's F 3 is used by both Actor A 4 and Actor A 6 , both via HIP 5 .
  • Some Actors may also have multiple needs, meaning they connect to more than one other Actor on the left, e.g. A 4 connects to A 2 for F 2 A and A 3 for F 3 .
  • HIP 1 is necessary for A 2 to access function F 1 A.
  • HIP 2 is necessary for A 3 to access function FIB.
  • the Licensing Regime obligates Actors A 2 and A 3 to use HIP 3 , HIP 4 , or HIP 5 when a requesting party tries to access F 2 A or F 2 B or F 3 , as follows.
  • HIP 3 is necessary for A 3 to access function F 2 B.
  • HIP 4 is necessary for A 4 to access function F 2 A.
  • HIP 5 is necessary for A 4 or A 6 to access function F 3 .
  • the Licensing Regime obligates Actors A 4 to use HIP 6 , or HIP 7 when a requesting party tries to access F 4 A or F 4 B.
  • HIP 6 is necessary for A 5 to access function F 4 A.
  • HIP 7 is necessary for A 6 to access function F 4 B.
  • the Licensing Regime contracts signed by an ecosystem Actor thus obligate it to use the chosen Hook IP to implement functions as depicted in FIG. 6 .
  • Those contracts may obligate an actor to use one form of Hook IP when acting as a Claimant through an API to some other actor, and a different form of Hook IP when acting as a Verifier through a different API to some different other actor.
  • FIG. 7 shows in table form the functions and obligations implemented in FIG. 6 .
  • FIGS. 6-7 can be extended ad infinitum, pulling other Actors into the Licensing Regime to implement any arbitrary set of legal obligation relationships among the Licensing Entity, all Actors, and all Actor's functions that they provide to the ecosystem, where this is achieved using various different types of Hook IP.
  • Hook IP Type data item, such as a 16 bit data field.
  • Hook IP Type would easily allow 65,536 different variations of the same basic type of Hook IP.
  • the Admin Info could also contain encryption keys for added security characteristics, or entitlement lists of other control data used to instantiate more complex control scenarios.
  • a Licensing Entity could create a very wide range of coarse or fine grain control mechanisms for an ecosystem.
  • the LICENT has rights to license Hook IP “X,” “Y,” and “Z” (HIPX, HIPY and HIPZ) to use in propagating the LICREG to different parties.
  • HIPX, HIPY and HIPZ are based on a cryptographic one way function used in the Handshake.
  • a CAS & DRM (CASDRM) provides an “Actor 1 ”, also known as the “Alpha Actor”.
  • Cable Middleware (MIDDLEWARE) provides “Actor 2 ”, or the “Beta Actor”.
  • a Guide Vendor provides “Actor 4 ”, the “Gamma Actor”.
  • a set-top-box browser (BROWSER) provides “Actor 5 ”, a “Delta Actor”.
  • CASDRM persuades the Actor 1 , CASDRM, to be the Alpha Actor by signing up the LICREG.
  • CASDRM will use HIPX as a Handshake Verifier, and has no role or Hook IP for any Claimant role.
  • HIPX Handshake Verifier
  • the fact that CASDRM is now a Licensee is made public knowledge, along with the fact that no one can get access to CASDRM functions in the Ecosystem without exercising the CASDRM API as a Verifier, which uses the Handshake, which uses HIPX, which requires LICREG.
  • MIDDLEWARE and GUIDE become aware that they both need access to the functions of CASDRM.
  • MIDDLEWARE and GUIDE both sign up to LICREG to gain such CASDRM access.
  • MIDDLEWARE and GUIDE's new LICREG grants them use of HIPX for CASDRM access as a Claimant, and also contains the obligation for them to use HIPY as a Verifier for any party that seeks to access MIDDLEWARE or the GUIDE's functions.
  • MIDDLEWARE and GUIDE are both Licensees
  • MIDDLEWARE or GUIDE are both Licensees
  • Both MIDDLEWARE and GUIDE will use HIPX when accessing CASDRM as Claimants, and will use HIPY as Verifiers when any other party tries to access their functions.
  • GUIDE now becomes aware that he needs access to the functions of MIDDLEWARE as well as CASDRM.
  • GUIDE signs up to additional LICREG terms to gain such additional access to MIDDLEWARE, which grant allows GUIDE to use HIPY as a Handshake Claimant to access MIDDLEWARE.
  • GUIDE's LICREG contains further obligations for him to use HIPY as a Verifier for any party GUIDE uses to source guide data to GUIDE's program guide application.
  • GUIDE signing up for HIPY will draw the program guide data provider that supplies GUIDE into the ecosystem, in that GUIDE can only choose a provider that is also licensed to HIPY as a Claimant.
  • the choice of guide data provider is subject to LICREG because the GUIDE is subject to LICREG.
  • BROWSER becomes aware that he needs access to the functions of MIDDLEWARE.
  • the BROWSER signs up to LICREG to gain such access as a HIPY Claimant.
  • BROWSER's LICREG contains further obligations for him to use HIPZ for any web site that BROWSER accesses. This will draw all web site sources accessible from BROWSER into the ecosystem.
  • the web site sources may not be subject to LICREG.
  • the choice of those web site sources is subject to LICREG because the BROWSER is subject to LICREG.
  • LICENT controls the ecosystem to a highly pervasive degree. This control not only includes the ecosystem Actors CASDRM, MIDDLEWARE, GUIDE, and BROWSER, but also to a lesser extent the provider of guide data and even the web sites accessible through the BROWSER.
  • a more nominal version of a controlled ecosystem may omit any controls over BROWSER, Web Sites, and the Guide Data Provider.
  • This aggressive example does illustrate how extensive controls could be established over an ecosystem using the techniques herein, which would impose the contractual obligations described upon Actors CASDRM, MIDDLEWARE, GUIDE, BROWSER, the provider of guide data to GUIDE, and the web sites accessible through BROWSER.
  • FIG. 8 provides a diagram of this example controlled ecosystem. Observe in FIG. 8 that the Guide Data Provider 810 and the Web Sites 812 are not so completely drawn into the ecosystem's contractual obligations as are CASDRM 802 , MIDDLEWARE 804 , GUIDE 806 , or BROWSER 808 . They would have Licensing Regime 800 obligations with regard to how BROWSER 808 and GUIDE 806 work with them, but they would not have obligations to further propagate the ecosystem to any other parties.
  • CASDRM is a HIPX Verifier Licensee only.
  • MIDDLEWARE has LICREG licenses to HIPX as a Claimant and HIPY as a Verifier.
  • GUIDE has LICREG licenses to HIPX as a Claimant and HIPY as both Verifier and Claimant.
  • BROWSER has LICREG licenses to HIPY as a Claimant and HIPZ as a Verifier.
  • the Guide Data Provider has a LICREG license to HIPY as a Claimant.
  • the Web Sites accessed by BROWSER have LICREG license to HIPZ only if that option is elected.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Software Systems (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Technology Law (AREA)
  • Computing Systems (AREA)
  • Library & Information Science (AREA)
  • Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • General Health & Medical Sciences (AREA)
  • Storage Device Security (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
US14/066,591 2012-10-29 2013-10-29 BUSINESS METHOD INCLUDING CHALLENGE-RESPONSE SYSTEM TO SECURELY AUTHENTICATE SOFTWARE APPLICATION PROGRAM INTERFACES (APIs) Abandoned US20140123220A1 (en)

Priority Applications (7)

Application Number Priority Date Filing Date Title
KR1020157014437A KR101722868B1 (ko) 2012-10-29 2013-10-29 소프트웨어 애플리케이션 프로그램 인터페이스들(api들)을 보안 인증하기 위한 챌린지-응답 시스템을 포함하는 비즈니스 방법
US14/066,591 US20140123220A1 (en) 2012-10-29 2013-10-29 BUSINESS METHOD INCLUDING CHALLENGE-RESPONSE SYSTEM TO SECURELY AUTHENTICATE SOFTWARE APPLICATION PROGRAM INTERFACES (APIs)
MX2015005454A MX355757B (es) 2012-10-29 2013-10-29 Metodo de negocios que incluye un sistema de desafio-respuesta para autenticar de forma segura interfaces de programa de aplicaciones de software (apis).
PCT/US2013/067353 WO2014070800A1 (en) 2012-10-29 2013-10-29 BUSINESS METHOD INCLUDING CHALLENGE-RESPONSE SYSTEM TO SECURELY AUTHENTICATE SOFTWARE APPLICATION PROGRAM INTERFACES (APIs)
AU2013338059A AU2013338059B2 (en) 2012-10-29 2013-10-29 METHOD INCLUDING CHALLENGE-RESPONSE SYSTEM TO SECURELY AUTHENTICATE SOFTWARE APPLICATION PROGRAM INTERFACES (APLs)
BR112015009690A BR112015009690A8 (pt) 2012-10-29 2013-10-29 Método de negócios incluindo um sistema de resposta a desafio para a autenticação de forma segura de interfaces de programa aplicativo (apis) de software
CA2899385A CA2899385C (en) 2012-10-29 2013-10-29 Handshaking protocol for secure transfer of data

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US201261719928P 2012-10-29 2012-10-29
US201261719923P 2012-10-29 2012-10-29
US14/066,591 US20140123220A1 (en) 2012-10-29 2013-10-29 BUSINESS METHOD INCLUDING CHALLENGE-RESPONSE SYSTEM TO SECURELY AUTHENTICATE SOFTWARE APPLICATION PROGRAM INTERFACES (APIs)

Publications (1)

Publication Number Publication Date
US20140123220A1 true US20140123220A1 (en) 2014-05-01

Family

ID=50548740

Family Applications (4)

Application Number Title Priority Date Filing Date
US14/066,653 Active 2033-11-08 US9172981B2 (en) 2012-10-29 2013-10-29 Challenge-response cable set-top-box system to securely authenticate software application program interfaces (APIs)
US14/066,591 Abandoned US20140123220A1 (en) 2012-10-29 2013-10-29 BUSINESS METHOD INCLUDING CHALLENGE-RESPONSE SYSTEM TO SECURELY AUTHENTICATE SOFTWARE APPLICATION PROGRAM INTERFACES (APIs)
US14/066,657 Active US9027159B2 (en) 2012-10-29 2013-10-29 Handshake protocol to control actors and functions in a cable set-top-box system to propagate acceptance of an IP license to securely authenticate software application program interfaces (APIs)
US14/066,636 Active 2034-02-21 US9197910B2 (en) 2012-10-29 2013-10-29 Business method including handshake protocol to control actors and functions to propagate acceptance of an IP license to securely authenticate software application program interfaces (APIs)

Family Applications Before (1)

Application Number Title Priority Date Filing Date
US14/066,653 Active 2033-11-08 US9172981B2 (en) 2012-10-29 2013-10-29 Challenge-response cable set-top-box system to securely authenticate software application program interfaces (APIs)

Family Applications After (2)

Application Number Title Priority Date Filing Date
US14/066,657 Active US9027159B2 (en) 2012-10-29 2013-10-29 Handshake protocol to control actors and functions in a cable set-top-box system to propagate acceptance of an IP license to securely authenticate software application program interfaces (APIs)
US14/066,636 Active 2034-02-21 US9197910B2 (en) 2012-10-29 2013-10-29 Business method including handshake protocol to control actors and functions to propagate acceptance of an IP license to securely authenticate software application program interfaces (APIs)

Country Status (8)

Country Link
US (4) US9172981B2 (ko)
EP (1) EP2901349A1 (ko)
KR (1) KR101722868B1 (ko)
AU (1) AU2013338059B2 (ko)
BR (1) BR112015009690A8 (ko)
CA (1) CA2899385C (ko)
MX (1) MX355757B (ko)
WO (1) WO2014070800A1 (ko)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9172981B2 (en) 2012-10-29 2015-10-27 Arris Technology, Inc. Challenge-response cable set-top-box system to securely authenticate software application program interfaces (APIs)
US9565022B1 (en) * 2013-07-02 2017-02-07 Impinj, Inc. RFID tags with dynamic key replacement
US10656874B2 (en) * 2015-10-28 2020-05-19 Huawei Technologies Co., Ltd. Storage device operation control method, and storage device
WO2021056069A1 (en) * 2019-09-25 2021-04-01 Commonwealth Scientific And Industrial Research Organisation Cryptographic services for browser applications

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9258274B2 (en) * 2014-07-09 2016-02-09 Shape Security, Inc. Using individualized APIs to block automated attacks on native apps and/or purposely exposed APIs
US10050935B2 (en) 2014-07-09 2018-08-14 Shape Security, Inc. Using individualized APIs to block automated attacks on native apps and/or purposely exposed APIs with forced user interaction
US9729506B2 (en) 2014-08-22 2017-08-08 Shape Security, Inc. Application programming interface wall
US9800602B2 (en) 2014-09-30 2017-10-24 Shape Security, Inc. Automated hardening of web page content
US20170061131A1 (en) * 2015-08-31 2017-03-02 Cisco Technology, Inc. Side-Channel Integrity Validation of Devices
CN106778341A (zh) * 2016-12-02 2017-05-31 华北计算技术研究所（中国电子科技集团公司第十五研究所） 数据权限管理系统及方法

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020035544A1 (en) * 2000-09-06 2002-03-21 Satoru Wakao Method and apparatus for forming content, method and apparatus for reproducing content and computer readable storage medium
US20100257350A1 (en) * 2007-11-16 2010-10-07 Thomson Licensing System and method for tracking a downloaded digital media file
US20110129087A1 (en) * 2009-11-30 2011-06-02 General Instrument Corporation System and Method for Encrypting and Decrypting Data
US8635664B2 (en) * 2007-12-28 2014-01-21 Intel Corporation Method and system for securing application program interfaces in unified extensible firmware interface

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4860353A (en) 1988-05-17 1989-08-22 General Instrument Corporation Dynamic feedback arrangement scrambling technique keystream generator
US6850252B1 (en) * 1999-10-05 2005-02-01 Steven M. Hoffberg Intelligent electronic appliance system and method
US6961427B1 (en) 1999-11-23 2005-11-01 General Instrument Corporation Methods and apparatus for keystream generation
CN1764883A (zh) * 2003-03-24 2006-04-26 松下电器产业株式会社 数据保护管理装置和数据保护管理方法
US7383438B2 (en) * 2004-12-18 2008-06-03 Comcast Cable Holdings, Llc System and method for secure conditional access download and reconfiguration
JP4589758B2 (ja) * 2005-03-03 2010-12-01 フェリカネットワークス株式会社 データ通信システム，代行システムサーバ，コンピュータプログラム，およびデータ通信方法
US8713705B2 (en) * 2009-08-03 2014-04-29 Eisst Ltd. Application authentication system and method
US8898469B2 (en) 2010-02-05 2014-11-25 Motorola Mobility Llc Software feature authorization through delegated agents
US8813202B2 (en) * 2012-01-03 2014-08-19 General Instrument Corporation Mechanism to determine source device service tier based on the version of the HDCP key
CA2899385C (en) 2012-10-29 2020-10-13 Arris Technology, Inc. Handshaking protocol for secure transfer of data

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020035544A1 (en) * 2000-09-06 2002-03-21 Satoru Wakao Method and apparatus for forming content, method and apparatus for reproducing content and computer readable storage medium
US20100257350A1 (en) * 2007-11-16 2010-10-07 Thomson Licensing System and method for tracking a downloaded digital media file
US8635664B2 (en) * 2007-12-28 2014-01-21 Intel Corporation Method and system for securing application program interfaces in unified extensible firmware interface
US20110129087A1 (en) * 2009-11-30 2011-06-02 General Instrument Corporation System and Method for Encrypting and Decrypting Data

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9172981B2 (en) 2012-10-29 2015-10-27 Arris Technology, Inc. Challenge-response cable set-top-box system to securely authenticate software application program interfaces (APIs)
US9197910B2 (en) 2012-10-29 2015-11-24 Arris Technology, Inc. Business method including handshake protocol to control actors and functions to propagate acceptance of an IP license to securely authenticate software application program interfaces (APIs)
US9565022B1 (en) * 2013-07-02 2017-02-07 Impinj, Inc. RFID tags with dynamic key replacement
US9887843B1 (en) 2013-07-02 2018-02-06 Impinj, Inc. RFID tags with dynamic key replacement
US10084597B1 (en) 2013-07-02 2018-09-25 Impinj, Inc. RFID tags with dynamic key replacement
US10656874B2 (en) * 2015-10-28 2020-05-19 Huawei Technologies Co., Ltd. Storage device operation control method, and storage device
WO2021056069A1 (en) * 2019-09-25 2021-04-01 Commonwealth Scientific And Industrial Research Organisation Cryptographic services for browser applications

Also Published As

Publication number Publication date
AU2013338059A1 (en) 2015-06-18
US9172981B2 (en) 2015-10-27
US9197910B2 (en) 2015-11-24
BR112015009690A8 (pt) 2023-02-07
CA2899385A1 (en) 2014-05-08
AU2013338059B2 (en) 2017-06-15
BR112015009690A2 (pt) 2018-05-22
MX355757B (es) 2018-04-27
EP2901349A1 (en) 2015-08-05
MX2015005454A (es) 2016-01-15
US9027159B2 (en) 2015-05-05
US20140123321A1 (en) 2014-05-01
KR101722868B1 (ko) 2017-04-05
WO2014070800A1 (en) 2014-05-08
CA2899385C (en) 2020-10-13
KR20150081328A (ko) 2015-07-13
US20140123242A1 (en) 2014-05-01
US20140123172A1 (en) 2014-05-01

Similar Documents

Publication Publication Date Title
US9027159B2 (en) Handshake protocol to control actors and functions in a cable set-top-box system to propagate acceptance of an IP license to securely authenticate software application program interfaces (APIs)
US8838977B2 (en) Watermark extraction and content screening in a networked environment
US8539240B2 (en) Rights object authentication in anchor point-based digital rights management
US8561210B2 (en) Access to domain
US9438584B2 (en) Provisioning DRM credentials on a client device using an update server
KR101548753B1 (ko) 컨텐츠 공유 방법
US10055553B2 (en) PC secure video path
CN101938468B (zh) 数字内容保护系统
US20060282391A1 (en) Method and apparatus for transferring protected content between digital rights management systems
KR100999829B1 (ko) 디바이스들 사이의 클래스－기반 콘텐트 전달
Kravitz et al. Achieving media portability through local content translation and end-to-end rights management
US8020214B2 (en) Transmitter, receiver, and content transmitting and receiving method
WO2006026056A1 (en) Enforcing a drm / ipmp agreement in a multimedia content distribution network
KR20160108072A (ko) 콘텐츠 제공 시스템 및 방법

Legal Events

Date Code Title Description
AS Assignment

Owner name: GENERAL INSTRUMENT CORPORATION, PENNSYLVANIA

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:SPRUNK, ERIC J.;DEPIETRO, MARK G.;MEDVINSKY, ALEXANDER;AND OTHERS;SIGNING DATES FROM 20131204 TO 20131211;REEL/FRAME:031792/0758

AS Assignment

Owner name: ARRIS TECHNOLOGY, INC., GEORGIA

Free format text: MERGER AND CHANGE OF NAME;ASSIGNOR:GENERAL INSTRUMENT CORPORATION;REEL/FRAME:035176/0620

Effective date: 20150101

Owner name: ARRIS TECHNOLOGY, INC., GEORGIA

Free format text: MERGER AND CHANGE OF NAME;ASSIGNORS:GENERAL INSTRUMENT CORPORATION;GENERAL INSTRUMENT CORPORATION;REEL/FRAME:035176/0620

Effective date: 20150101

AS Assignment

Owner name: BANK OF AMERICA, N.A., AS ADMINISTRATIVE AGENT, NORTH CAROLINA

Free format text: SECURITY INTEREST;ASSIGNORS:ARRIS GROUP, INC.;ARRIS ENTERPRISES, INC.;ARRIS INTERNATIONAL LIMITED;AND OTHERS;REEL/FRAME:036020/0789

Effective date: 20150618

Owner name: BANK OF AMERICA, N.A., AS ADMINISTRATIVE AGENT, NO

Free format text: SECURITY INTEREST;ASSIGNORS:ARRIS GROUP, INC.;ARRIS ENTERPRISES, INC.;ARRIS INTERNATIONAL LIMITED;AND OTHERS;REEL/FRAME:036020/0789

Effective date: 20150618

STCB Information on status: application discontinuation

Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION

AS Assignment

Owner name: ARRIS ENTERPRISES, INC., PENNSYLVANIA

Free format text: TERMINATION AND RELEASE OF SECURITY INTEREST IN PATENTS;ASSIGNOR:BANK OF AMERICA, N.A., AS ADMINISTRATIVE AGENT;REEL/FRAME:050721/0401

Effective date: 20190404

Owner name: NEXTLEVEL SYSTEMS (PUERTO RICO), INC., PENNSYLVANI

Free format text: TERMINATION AND RELEASE OF SECURITY INTEREST IN PATENTS;ASSIGNOR:BANK OF AMERICA, N.A., AS ADMINISTRATIVE AGENT;REEL/FRAME:050721/0401

Effective date: 20190404

Owner name: GIC INTERNATIONAL HOLDCO LLC, PENNSYLVANIA

Free format text: TERMINATION AND RELEASE OF SECURITY INTEREST IN PATENTS;ASSIGNOR:BANK OF AMERICA, N.A., AS ADMINISTRATIVE AGENT;REEL/FRAME:050721/0401

Effective date: 20190404

Owner name: ARRIS GLOBAL SERVICES, INC., PENNSYLVANIA

Free format text: TERMINATION AND RELEASE OF SECURITY INTEREST IN PATENTS;ASSIGNOR:BANK OF AMERICA, N.A., AS ADMINISTRATIVE AGENT;REEL/FRAME:050721/0401

Effective date: 20190404

Owner name: ARCHIE U.S. MERGER LLC, PENNSYLVANIA

Free format text: TERMINATION AND RELEASE OF SECURITY INTEREST IN PATENTS;ASSIGNOR:BANK OF AMERICA, N.A., AS ADMINISTRATIVE AGENT;REEL/FRAME:050721/0401

Effective date: 20190404

Owner name: ARCHIE U.S. HOLDINGS LLC, PENNSYLVANIA

Free format text: TERMINATION AND RELEASE OF SECURITY INTEREST IN PATENTS;ASSIGNOR:BANK OF AMERICA, N.A., AS ADMINISTRATIVE AGENT;REEL/FRAME:050721/0401

Effective date: 20190404

Owner name: ARRIS GROUP, INC., PENNSYLVANIA

Free format text: TERMINATION AND RELEASE OF SECURITY INTEREST IN PATENTS;ASSIGNOR:BANK OF AMERICA, N.A., AS ADMINISTRATIVE AGENT;REEL/FRAME:050721/0401

Effective date: 20190404

Owner name: JERROLD DC RADIO, INC., PENNSYLVANIA

Free format text: TERMINATION AND RELEASE OF SECURITY INTEREST IN PATENTS;ASSIGNOR:BANK OF AMERICA, N.A., AS ADMINISTRATIVE AGENT;REEL/FRAME:050721/0401

Effective date: 20190404

Owner name: GIC INTERNATIONAL CAPITAL LLC, PENNSYLVANIA

Free format text: TERMINATION AND RELEASE OF SECURITY INTEREST IN PATENTS;ASSIGNOR:BANK OF AMERICA, N.A., AS ADMINISTRATIVE AGENT;REEL/FRAME:050721/0401

Effective date: 20190404

Owner name: ARRIS TECHNOLOGY, INC., PENNSYLVANIA

Free format text: TERMINATION AND RELEASE OF SECURITY INTEREST IN PATENTS;ASSIGNOR:BANK OF AMERICA, N.A., AS ADMINISTRATIVE AGENT;REEL/FRAME:050721/0401

Effective date: 20190404

Owner name: BIG BAND NETWORKS, INC., PENNSYLVANIA

Free format text: TERMINATION AND RELEASE OF SECURITY INTEREST IN PATENTS;ASSIGNOR:BANK OF AMERICA, N.A., AS ADMINISTRATIVE AGENT;REEL/FRAME:050721/0401

Effective date: 20190404

Owner name: ARRIS SOLUTIONS, INC., PENNSYLVANIA

Free format text: TERMINATION AND RELEASE OF SECURITY INTEREST IN PATENTS;ASSIGNOR:BANK OF AMERICA, N.A., AS ADMINISTRATIVE AGENT;REEL/FRAME:050721/0401

Effective date: 20190404

Owner name: ARRIS HOLDINGS CORP. OF ILLINOIS, INC., PENNSYLVAN

Free format text: TERMINATION AND RELEASE OF SECURITY INTEREST IN PATENTS;ASSIGNOR:BANK OF AMERICA, N.A., AS ADMINISTRATIVE AGENT;REEL/FRAME:050721/0401

Effective date: 20190404

Owner name: ARRIS INTERNATIONAL LIMITED, PENNSYLVANIA

Free format text: TERMINATION AND RELEASE OF SECURITY INTEREST IN PATENTS;ASSIGNOR:BANK OF AMERICA, N.A., AS ADMINISTRATIVE AGENT;REEL/FRAME:050721/0401

Effective date: 20190404

Owner name: TEXSCAN CORPORATION, PENNSYLVANIA

Free format text: TERMINATION AND RELEASE OF SECURITY INTEREST IN PATENTS;ASSIGNOR:BANK OF AMERICA, N.A., AS ADMINISTRATIVE AGENT;REEL/FRAME:050721/0401

Effective date: 20190404

Owner name: POWER GUARD, INC., PENNSYLVANIA

Free format text: TERMINATION AND RELEASE OF SECURITY INTEREST IN PATENTS;ASSIGNOR:BANK OF AMERICA, N.A., AS ADMINISTRATIVE AGENT;REEL/FRAME:050721/0401

Effective date: 20190404

Owner name: NEXTLEVEL SYSTEMS (PUERTO RICO), INC., PENNSYLVANIA

Free format text: TERMINATION AND RELEASE OF SECURITY INTEREST IN PATENTS;ASSIGNOR:BANK OF AMERICA, N.A., AS ADMINISTRATIVE AGENT;REEL/FRAME:050721/0401

Effective date: 20190404

Owner name: ARRIS HOLDINGS CORP. OF ILLINOIS, INC., PENNSYLVANIA

Free format text: TERMINATION AND RELEASE OF SECURITY INTEREST IN PATENTS;ASSIGNOR:BANK OF AMERICA, N.A., AS ADMINISTRATIVE AGENT;REEL/FRAME:050721/0401

Effective date: 20190404