| Page Range | 14033-14052 | |
| FR Document | 2016-05763 |
[Federal Register Volume 81, Number 51 (Wednesday, March 16, 2016)] [Proposed Rules] [Pages 14033-14052] From the Federal Register Online [www.thefederalregister.org] [FR Doc No: 2016-05763] ======================================================================= ----------------------------------------------------------------------- FEDERAL COMMUNICATIONS COMMISSION 47 CFR Part 76 [MB Docket No. 16-42; CS Docket No. 97-80; FCC 16-18] Expanding Consumers' Video Navigation Choices; Commercial Availability of Navigation Devices AGENCY: Federal Communications Commission. ACTION: Proposed rule. ----------------------------------------------------------------------- SUMMARY: In this document, we propose new rules to empower consumers to choose how they wish to access the multichannel video programming to which they subscribe, and promote innovation in the display, selection, and use of this programming and of other video programming available to consumers. We take steps to fulfill our obligation under section 629 of the Communications Act to assure a commercial market for devices that can access multichannel video programming and other services offered over multichannel video programming systems. We propose rules intended to allow consumer electronics manufacturers, innovators, and other developers to build devices or software solutions that can navigate the universe of multichannel video programming with a competitive user interface. We also seek comment on outstanding issues related to our CableCARD rules. DATES: Submit comments on or before April 15, 2016. Submit reply comments on or before May 16, 2016. Written comments on the Paperwork Reduction Act proposed information collection requirements must be submitted by the public, Office of Management and Budget (OMB), and other interested parties on or before May 16, 2016. ADDRESSES: In addition to filing comments with the Secretary, a copy of any comments on the Paperwork Reduction Act (PRA) information collection requirements contained herein should be submitted to the Federal Communications Commission via email to [email protected] and to Nicholas A. Fraser, Office of Management and Budget, via email to [email protected] or via fax at 202-395-5167. FOR FURTHER INFORMATION CONTACT: For additional information on this proceeding, contact Brendan Murray, [email protected], of the Media Bureau, Policy Division, (202) 418-1573. Contact Cathy Williams, [email protected], (202) 418-2918 concerning PRA matters. SUPPLEMENTARY INFORMATION: Congress adopted section 629 of the Communications Act in 1996, and since then each era of technology has brought unique challenges to achieving Section 629's goals. When Congress first directed the Commission to adopt regulations to assure a commercial market for devices that can access multichannel video programming, the manner in which MVPDs offered their services made it difficult to achieve the statutory purpose. Cable operators used widely varying security technologies, and the best standard available to the Commission was the hardware-based CableCARD standard--which the cable and consumer electronics industries jointly developed--that worked only with one-way cable services. In 2010, the Commission sought comment on a new approach that would work with two-way services, but still only a hardware solution would work because software-based security was not sophisticated enough to meet content companies' content protection demands. This concept, called ``AllVid,'' would have allowed electronics manufacturers to offer retail devices that could access multichannel video programming, but would have required all operators to put a new device in the home between the network and the retail or leased set-top box. Now, as MVPDs move to Internet Protocol (``IP'') to deliver their services and to move content throughout the home, those difficulties are gone. Today, MVPDs provide ``control channel'' data that contains (1) the channels and programs they carry, (2) whether a consumer has the right to access each of those channels and programs, and (3) the usage rights that a consumer has with respect to those channels and programs. Many MVPDs already use Internet Protocol (``IP'') to provide this control channel data. Moreover, most MVPDs have coalesced around a few standards and specifications for delivery of the video content itself, and many have progressed to sending content throughout the home network via IP. This standardization and increasing reliance on IP allows for software solutions that, with ground rules to ensure a necessary degree of convergence, will make it easier to finally fulfill the purpose of Section 629. The regulatory and technological path to this proceeding reflects a long history. It begins with the Telecommunications Act of 1996, when Congress added Section 629 to the Communications Act. Section 629 directs the Commission to adopt regulations to assure the commercial availability of devices that consumers use to access multichannel video programming and other services offered over multichannel video programming networks. Section 629 goes on to state that these devices should be available from ``manufacturers, retailers, and other vendors not affiliated with any multichannel video programming distributor.'' It also prohibits the Commission from adopting regulations that would ``jeopardize security of multichannel video programming and other services offered over multichannel video programming systems, or impede the legal rights of a provider of such services to prevent theft of service.'' In enacting the section, Congress pointed to the vigorous retail market for customer premises equipment used with the telephone network and sought to create a similarly vigorous market for devices used with services offered over MVPDs' networks. The Commission first adopted rules to implement Section 629 in 1998, just as ``the enormous technological change resulting from the movement from analog to digital communications [was] underway.'' The Commission set fundamental ground rules for consumer-owned devices and access to services offered over multichannel video programming systems. The rules established (1) manufacturers' right to build, and consumers' right to attach, any non-harmful device to an MVPD network, (2) a requirement that MVPDs provide technical interface information so manufacturers, retailers, and subscribers could determine device compatibility, (3) a requirement that MVPDs make available a separate security element that would allow a set-top box built by an unaffiliated manufacturer to access encrypted multichannel video programming without jeopardizing security of programming or impeding the legal rights of MVPDs to prevent theft of service, and (4) the integration ban, which required MVPDs to commonly [[Page 14034]] rely on the separated security in the devices that they lease to subscribers. The Commission did not initially impose a specific technical standard to achieve these rules, but instead adopted rules that relied ``heavily on the representations of the various interests involved that they will agree on relevant specifications, interfaces, and standards in a timely fashion.'' In December 2002, the cable and consumer electronics industries adopted a Memorandum of Understanding regarding a one-way plug-and-play ``CableCARD'' compatibility standard for digital cable. In October 2003, the Commission adopted the CableCARD standard as part of the Commission's rules, and consumer electronics manufacturers brought unidirectional CableCARD-compatible devices to market less than a year later. At least six million (and by one report, over 15 million) CableCARD devices were built and shipped, but the nine largest incumbent cable operators have deployed only 618,000 CableCARDs for use in consumer-owned devices. These rules drove innovations that consumers value greatly today: High-definition digital video recording, competitive user interfaces that provided more program information to viewers, the ability to set recordings remotely, the incorporation of Internet content with cable content, and automatic commercial skipping on cable content. Throughout the mid-to-late 2000s, cable operators increasingly transitioned their systems to digital and introduced interactive video services such as video-on-demand and content delivery methods such as switched digital video. The Commission's CableCARD rules and the Memorandum of Understanding did not prescribe methods for retail devices to access those interactive services, and therefore retail CableCARD devices could not access cable video-on-demand services. Moreover, cable operators generally offered poor CableCARD support, which made it much more difficult for consumers to set up a retail device than a leased device. In 2010, the Commission took steps to remedy problems with the CableCARD regime. The Commission adopted additional CableCARD-related rules to improve cable operator support for retail CableCARD devices. The Commission also sought comment on a successor technology in the form of a Commission-designed, standardized converter box that would be designed to allow ``any electronics manufacturer to offer smart video devices at retail that can be used with the services of any MVPD and without the need to coordinate or negotiate with MVPDs.'' The Commission sought comment on this AllVid concept in a Notice of Inquiry but ultimately decided not to propose rules to mandate it. In late 2014, Congress passed STELAR. Section 106 of that law had two main purposes: First, it eliminated the integration ban as of December 4, 2015, and second, it directed the Chairman of the Commission to appoint an advisory committee of technical experts to recommend a system for downloadable security that could advance the goals of section 629. The Chairman appointed 19 members to the Downloadable Security Technical Advisory Committee (``DSTAC''), and the committee submitted its report to the Commission on August 28, 2015. The DSTAC Report gave an account of the increasing number of devices on which consumers are viewing video content, including laptops, tablets, phones, and other ``smart,'' Internet-connected devices. The DSTAC Report pointed to two main reasons for this shift: (1) Software-based applications have made it easier for content providers to tailor their services to run on different hardware, and (2) there are an increasing number of software-based content protection systems that copyright holders are comfortable relying on to protect their content. The Media Bureau released a Public Notice seeking comment on the DSTAC Report on August 30, 2015. The DSTAC Report and comments that we received in response to it underlie and inform our Notice of Proposed Rulemaking. The DSTAC Report offered two proposals regarding the non-security elements and two proposals regarding the security elements of a system that could implement section 629. For the non-security elements, the DSTAC Report presented both an MVPD-supported proposal that is based on proprietary applications and would allow MVPDs to retain control of the consumer experience, and a consumer electronics-supported proposal that is based on standard protocols that would let a competing device or application offer a consumer experience other than the one the MVPD offers. With respect to security, the DSTAC Report presented both an MVPD-supported proposal based on digital rights management (similar to what Internet-based video services use to protect their video content), and a consumer electronics-supported proposal based on link protection (similar to how content is protected as it travels from a Blu-ray player to a television set). In this Notice of Proposed Rulemaking, we propose rules that are intended to assure a competitive market for equipment, including software, that can access multichannel video programming. A recent news report on this topic summarized the issue succinctly: ``some consumer advocates wonder why, if you do want a set-top box, you can't just buy one as easily as you'd buy a cell phone or TV for that matter.'' Before MVPDs transitioned to digital service, it was easy for consumers to buy televisions that received cable service without the need for a set-top box. In 1996, Congress recognized that we were on the cusp of a digital world with diverging system architectures. To address this, Congress adopted Section 629, and the Commission implemented that section of the statute by separating the parts of cable system architectures that were not consistent among systems into a module called a CableCARD that cable operators could design to work with their system-specific technology. This module converted system-specific aspects into a standardized interface; this standardized interface allowed a manufacturer to build a single device that could work with cable systems nationwide, despite their divergent technologies. Today, the world is converging again, this time around IP to provide control channel data, in some cases also using IP for content delivery over MVPD systems, and in many cases using IP for content delivery throughout the home. Standards will allow us to develop, and MVPDs to follow, ground rules about compatibility that are technology-neutral: The rules will allow MVPDs to upgrade their networks freely and any changes that a navigation device needs to conform to those changes can be supplied via software download rather than upgrading consumers' hardware. The ground rules we propose in this Notice of Proposed Rulemaking are designed to let MVPD subscribers watch what they pay for wherever they want, however they want, and whenever they want, and pay less money to do so, making it as easy to buy an innovative means of accessing multichannel video programming (such as an app, smart TV, or set-top box) as it is to buy a cell phone or TV. As discussed below, our proposed rules are based on three fundamental points. First, the market for navigation devices is not competitive. Second, the few successes that developed in the CableCARD regime demonstrate that competitive navigation--that is, competition in the user interface and complementary features--is essential to achieve the goals of Section 629. Third, entities that build competitive navigation devices, including [[Page 14035]] applications, need to be able to build those devices without seeking permission from MVPDs, because MVPDs offer products that directly compete with navigation devices and therefore have an incentive to withhold permission or constrain innovation, which would frustrate Section 629's goal of assuring a commercial market for navigation devices. The Need for Rules. Today, consumers have few alternatives to leasing set-top boxes from their MVPDs, and the vast majority of MVPD subscribers lease boxes from their MVPD. In July 2015, Senators Ed Markey and Richard Blumenthal reported statistics that they gathered from a survey of large MVPDs: ``approximately 99 percent of customers rent[ ] their set-top box directly from their pay-TV provider, [and] the set-top box rental market may be worth more than $19.5 billion per year, with the average American household spending more than $231 per year on set-top box rental fees.'' There is evidence that increasingly consumers are able to access video service through proprietary MVPD applications as well. According to NCTA, consumers have downloaded MVPD Android and iOS applications more than 56 million times, more than 460 million IP-enabled devices support one or more MVPD applications, and 66 percent of them support applications from all of the top-10 MVPDs. These statistics show, however, that almost all consumers have one source for access to the multichannel video programming to which they subscribe: The leased set-top box, or the MVPD-provided application. Therefore, we tentatively conclude that the market for navigation devices is not competitive, and that we should adopt new regulations to further Section 629. We invite comment on this tentative conclusion. Certain MVPD commenters argue that the market for devices is competitive and that we need not adopt any new regulations to achieve Section 629's directive. They argue that the popularity of streaming devices such as Amazon Fire TV, AppleTV, Chromecast, Roku, assorted video game systems, and mobile devices that can access over-the-top services such as Netflix, Amazon Instant Streaming, and Hulu, shows that Congress's goals in section 629 have been met. We disagree. With certain limited exceptions, it appears that those devices are not ``used by consumers to access multichannel video programming,'' and are even more rarely used as the sole means of accessing MVPDs' programming. We seek comment on this point. Which MVPDs allow their subscribers to use these devices as their sole means of accessing multichannel video programming? We seek specific numbers from MVPDs on the number of and percentage of their subscribers who use such devices as their sole means of accessing multichannel video programming without any MVPD-owned equipment in the subscriber's home. How do these numbers compare to other commercial markets for consumer electronics? MVPDs may have several incentives for maintaining control over the user interface through which consumers access their multichannel video programming service, but for the reasons we provide below, we believe that the Act requires competitive navigation that would allow third parties to develop innovative ways to access multichannel video programming. We seek comment on those incentives. For example, how do MVPDs profit from their control of the user interface? Do MVPDs track consumer viewing habits, and if so, do they profit in any way as a result of that tracking (for example, by using the information to sell advertising or selling the information to ratings analytics companies)? What are the profit margins for selling that data? How long does a typical consumer lease a MVPD set-top box before it is replaced? What are MVPDs' profit margins on set-top boxes? Do MVPDs leverage their user interfaces to sell other services offered over multichannel video programming systems, e.g. home security? Do MVPDs offer integrated search across their multichannel video programming and other unaffiliated video services, and if not why not? In addition, in today's world a retail navigation device developer must negotiate with MVPDs to get permission to provide access to the MVPD's multichannel video programming, on the MVPD's terms. These business-to-business arrangements are a step in the right direction for consumers because the arrangements have increased the universe of devices they can use to receive service. The arrangements have not assured a competitive retail market for devices from unaffiliated sources as required by section 629 because they do not always provide access to all of the programming that a subscriber pays to access, and may limit features like recording. In other words, these business-to- business arrangements--typically in the form of proprietary apps--do not offer consumers viable substitutes to a full-featured, leased set- top box. Moreover, these relationships are purely at the discretion of the MVPD and, to date, have only provided access to the MVPD's user interface rather than that of the competitive device. Some argue that these business-to-business deals are essential to ensure that the few independent, diverse programmers that currently exist can continue to survive because they ensure that those programmers can rely on the channel placement and advertising agreements that they have contracted for with the MVPD. We disagree with this assertion, and believe that competition in interfaces, menus, search functions, and improved over-the-top integration will make it easier for consumers to find and watch minority and special interest programming. In addition, our goal is to preserve the contractual arrangements between programmers and MVPDs, while creating additional opportunities for programmers, who may not have an arrangement with an MVPD, to reach consumers. We seek comment on this analysis. We also seek specific comment on the process that an MVPD uses to decide whether to allow such a device to access its services. Have retail navigation device developers asked MVPDs to develop applications for their devices and been denied? Have MVPDs asked navigation device developers to carry their applications and been denied? Do programmers prohibit MVPDs from displaying their programming on certain devices? If so, what are the terms of those prohibitions? Should the Commission ban such terms to assure the commercial availability of devices that can access multichannel video programming, and under what authority? Are ``premium features and functions'' of devices such as televisions and recording devices limited due to ``cable scrambling, encoding, or encryption technologies?'' If so, could we adopt the rules we propose below pursuant to our authority under Section 624A of the Act? As noted above, it appears that consumers have downloaded proprietary MVPD applications many times; we seek comment on whether consumers actually use those applications to access multichannel video programming. Section 629 directs us to adopt regulations to assure the commercial availability of ``equipment used by consumers to access multichannel video programming.'' MVPDs argue that their proprietary applications are used by consumers to access multichannel video programming; to better evaluate this argument, we seek further comment on usage rates of those proprietary applications. What percentage of consumers use MVPD applications to view programming one month after [[Page 14036]] downloading an application? How many hours per month, on average, does a consumer use an MVPD application to view programming, compared to consumers' use of leased boxes? How many MVPDs make their full channel lineups available via applications? Do any MVPDs allow consumers to access multichannel video programming, beyond unencrypted signals, without leasing or purchasing some piece of MVPD equipment? How many consumers that lease a set-top box also use an MVPD application? How many consumers view multichannel video programming only via a proprietary MVPD application, without leasing a box? Are proprietary MVPD applications available on all platforms and devices? Or do MVPDs enter into agreements with a limited number of manufacturers or operating system vendors? Section 629 and DBS Providers. In the First Plug and Play Report and Order, the Commission exempted DBS providers from our foundational separation of security requirement because ``customer ownership of satellite earth stations receivers and signal decoding equipment has been the norm in the DBS field.'' This meant that DBS was also exempt from most of the rules that the Commission adopted in the Second Plug and Play Order. Unfortunately, in the intervening years the market did not evolve as we expected; in fact, from a navigation device perspective, it appears that the market for devices that can access DBS multichannel video programming has devolved to one that relies almost exclusively on equipment leased from the DBS provider. Accordingly, to implement the requirements of section 629 fully, we tentatively conclude that any regulations we adopt should apply to DBS. We seek comment on this tentative conclusion. We also seek comment on the availability of DBS equipment at retail. Has the state of the marketplace changed since 1998, when the Commission had observed an ``evolving'' competitive market for DBS equipment and, if so, to what extent? In addition to our authority under section 629, we seek comment on our authority under section 335 to adopt any of the rules we propose below or any other rules related to competition in the market for devices that can access DBS multichannel video programming, which would serve the public interest. Finally, we recognize the ``weirdness of satellite'' that the DSTAC emphasized in this context because the DBS systems cannot assume that bidirectional communication is available in all cases, and accordingly we seek comment on differences in DBS delivery or system architecture that should inform our proposed rules set forth below. Authority. We tentatively conclude that the Commission has legal authority to implement our proposed rules. Section 629 of the Act, entitled ``Competitive Availability of Navigation Devices,'' directs the Commission to ``adopt regulations to assure the commercial availability . . . of converter boxes, interactive communications equipment, and other equipment used by consumers to access multichannel video programming and other services offered over multichannel video programming systems, from manufacturers, retailers, and other vendors not affiliated with any multichannel video programming distributor.'' We propose to interpret the terms ``manufacturers, retailers, and other vendors'' broadly to include all hardware manufacturers, software developers, application designers, system integrators, and other such entities that are not affiliated with any MVPD and who are involved in the development of navigation devices or whose products enable consumers to access multichannel video programming over any such device. We believe a broad interpretation is necessary to ensure that these third parties are provided the information they need from MVPDs to facilitate the commercial development of competing navigation technologies in order to fulfill the goals of section 629. The Act does not define the terms ``navigation device'' or ``interactive communications equipment, and other equipment,'' but we believe that Congress intended the terms to be far broader than conventional cable boxes or other hardware alone; Section 629 is plainly written to cover any equipment used by consumers to access multichannel video programming and other services, and software features have long been essential elements of such equipment. Exercising our authority to interpret ambiguous terms in the Communications Act, we tentatively conclude that these terms include both the hardware and software (such as applications) employed in such devices that allow consumers to access multichannel video programming and other services offered over multichannel video programming systems. We believe this interpretation best serves the intent of Congress as reflected in the legislative history, which directs, among other things, that we ``should take cognizance of the current state of the marketplace.'' In today's marketplace, ``navigation devices''--i.e., interactive communications equipment and other equipment--include both hardware and software technologies. Certain functions can be performed interchangeably by either hardware, software, or a combination of both. Congress recognized this in the STELAR, which called for a study of downloadable software approaches to security issues previously performed in hardware. To fully and effectively implement Section 629 as Congress intended, we propose to interpret these terms to cover both the hardware and software aspects of navigation equipment. This is consistent with our interpretation of other sections of the Act that use the term ``equipment'', which we have interpreted to include both hardware and software. The Commission derived its definition of the term ``navigation devices'' in our current rules from the text of section 629, and we propose to interpret that term consistent with both the language and intent of the statute, as described above. We interpret the phrase ``manufacturers, retailers, and other vendors not affiliated with any multichannel video programming distributor'' in section 629 to mean broadly ``entities independent of MVPDs,'' such that our rules must ensure the availability of Navigation Devices from entities that have no business relationship with any MVPD for purposes of providing the three Information Flows that we discuss below. We believe that this interpretation best aligns with Congressional intent, as reflected in the legislative history of the Telecommunications Act of 1996. Namely, the House Report states that the statute was intended to encourage the availability of equipment from a ``variety of sources'' and ``various distribution sources'' to assure that consumers can buy a variety of non-proprietary devices. Moreover, we do not believe that the goals of section 629 would be met if the commercial market consisted solely of Navigation Devices built by developers with a business-to-business relationship with an MVPD, because such an approach would not lead to Navigation Device developers being able to innovate independently of MVPDs. We seek comment on this interpretation. Does it take proper account of the fact that even some Navigation Device developers that rely on the three Information Flows to provide access to MVPD service may have other business relationships with MVPDs unrelated to the provision of navigation devices? Are there other interpretations that can assure a [[Page 14037]] competitive market as Congress intended? We seek comment on this statutory analysis. Are there other sources of Commission authority to adopt the proposed rules? For example, we invite commenters to discuss the Commission's authority under Sections 624A and 335 of the Act and any other relevant statutory provisions. Alternatively, should we modify our definition of ``navigation devices'' to treat software on the device (such as an application) that consumers use to access multichannel video programming and other MVPD services as a ``navigation device,'' separate and apart from the hardware on which it is running? For example, we seek comment on whether we should add a sentence to our definition of ``navigation devices'' that states, ``This term includes software or hardware performing the functions traditionally performed in hardware navigation devices.'' Would such a modification be consistent with our statutory directive under section 629 to ``adopt regulations to assure the commercial availability . . . of converter boxes, interactive communications equipment, and other equipment'' used by consumers to access multichannel video programming and other services offered over MVPD systems? What implications would modification of our definition of ``navigation devices'' in this manner have on our current navigation devices rules? Would this definitional change impact Commission rules in other contexts? If so, commenters should identify the specific rule, how the definitional change would impact the rule, and whether further rule changes would be necessary to reflect the rule modification adopted in this proceeding. For example, would such a modification alter the accessibility obligations of device manufacturers and software developers and, if so, in what manner? Proposals. As discussed above, we do not believe that the current marketplace provides the ``commercial availability'' of competitive navigation devices by manufacturers, retailers, and other vendors not affiliated with any MVPD that can access multichannel video programming within the meaning of section 629. Given our experience to date, we believe that Section 629 cannot be satisfied--that is, we cannot assure a commercial market for devices that can access multichannel video programming--unless companies unaffiliated with an MVPD are able to offer innovative user interfaces and functionality to consumers wishing to access that multichannel video programming. This interpretation is in line with our current rules, which led to the creativity and consumer benefits of the CableCARD regime. We also believe that the goals of section 629 will not be met absent Commission action, given MVPDs' incentive to limit competition. As we begin to craft rules that will meet our 629 obligations, there are seven objectives that seem paramount to our effort. First, consumers should be able to choose how they access the multichannel video programming to which they subscribe (e.g., through the MVPD-provided user interface on an MVPD-provided set-top box or app, through a set-top box offered by an unaffiliated vendor, or through an application or search interface offered by an unaffiliated vendor on a device such as a tablet or smart TV). We propose a rule to define these ``Navigable Services'' as an MVPD's multichannel video programming (including both linear and on-demand programming), every format and resolution of that programming that the MVPD sends to its own devices and applications, and Emergency Alert System (EAS) messages, because we tentatively conclude that these elements are what comprise ``multichannel video programming'' as that term appears in section 629. We seek comment on this definition and whether there is information beyond the multichannel video programming and EAS messages that are essential parts of ``multichannel video programming and other services offered over multichannel video programming systems'' that a navigation system needs to access and that we should include in the definition. For example, if an MVPD offers a ``cloud recording'' service that allows consumers to record programs and store them remotely, should that cloud recording service be a ``Navigable Service''? We seek comment on how to define ``MVPD service.'' Second, we recognize that the few successful CableCARD devices all have something in common: They provide user interfaces that compete with the user interfaces MVPD-provided set-top boxes render. Therefore, MVPDs and unaffiliated vendors must be able to differentiate themselves in order to effectively compete based on the user interface and complementary features they offer users (e.g., integrated search across MVPD content and over-the-top content, suggested content, integration with home entertainment systems, caller ID, and future innovations). Third, unaffiliated vendors must be able to build competitive navigation devices, including applications, without first obtaining approval from MVPDs or organizations they control. Senators Markey and Blumenthal found that MVPDs take in approximately $19.5 billion per year in set-top box lease fees, so MVPDs have a strong financial incentive to use an approval process to prevent development of a competitive commercial market and continue to require almost all of their subscribers to lease set-top boxes. Fourth, unaffiliated vendors must implement content protection to ensure that the security of MVPD services is not jeopardized, and must respect licensing terms regarding copyright, entitlement, and robustness. This will ensure parity between MVPD-provided and competitive navigation devices. Fifth, our rules should be technology neutral, permitting both software (e.g., cloud delivery) and hardware solutions, and not impede innovation. This will ensure that consumers will not be forced to use outdated, power-hungry hardware to receive multichannel video programming services. Sixth, our rules should allow consumers to use the same device with different MVPDs throughout the country. Device portability will encourage MVPD competition because consumers will be able to change their video service providers without purchasing new equipment. Finally, our rules should not prescribe a particular solution that may impede the MVPD industry's technological progress. We seek comment on these seven objectives, their appropriateness, and in particular their relative importance. Based on our tentative conclusion that the market for navigation devices is not competitive, with the above objectives in mind, we propose rules that will assure a competitive market for devices that can access multichannel video programming without jeopardizing security of the programming or an MVPD's ability to prevent theft of service, as section 629 requires. Like the authors of the DSTAC Report, we split our discussion of these proposals into sections regarding the non- security and security elements of multichannel video programming services. The rules we propose are intended to address a fundamental feature of the current market for multichannel video programming services, namely the ``wide diversity in delivery networks, conditional access systems, bi-directional communication paths, and other technology choices across MVPDs (and even within MVPDs of a similar type).'' In 1998, the Commission concluded that it could address this technological diversity in one of two [[Page 14038]] ways, either via complex devices, or via translation of those diverse network technologies into a standardized format. This analysis stands seventeen years after it was adopted. We do not wish to impose a single, rigid, government-imposed technical standard on the parties, but we understand that it would be impossible to build widely used equipment without some standardization. Therefore, as explained further below, we propose to allow MVPDs to choose the specific standards they wish to use to make their services available via competitive navigation devices or solutions, so long as those standards are in a published, transparent format that conforms to specifications set by an open standards body. We also tentatively conclude that we should require MVPDs to comply with the rules we propose two years after adoption. We seek comment on this tentative conclusion. Non-Security Elements: Service Discovery, Entitlement, and Content Delivery. We propose an approach to non-security elements that balances the interests expressed by the members of the DSTAC and commenters who filed in response to the DSTAC Report. Under this approach, we will require MVPDs to provide Service Discovery, Entitlement, and Content Delivery information (the ``Information Flows'') in standardized formats that the MVPD chooses. Our proposal is based on the tentative conclusion that the Information Flows are necessary to ensure that developers that are not affiliated with an MVPD can develop navigation devices, including software, that can access multichannel video programming in a way that will assure a commercial market. We believe that this proposed requirement is the least burdensome way to assure commercial availability of navigation devices (the specifications necessary to provide these Information Flows appear to exist today) and is consistent with our prior rules. Moreover, this approach is technology neutral--the Commission would not dictate the MVPD's decision whether to rely on hardware or software to make the Information Flows available. Therefore, the proposed approach would provide each MVPD with flexibility to choose the standard that best aligns with its system architecture. It would also give unaffiliated entities access to the Information Flows in a published, transparent, and standardized format so that those entities would understand what information is available to them. We believe that this is the best approach because the proposal does not require the Commission to prescribe or even approve the standards so long as the Information Flows are available. A benefit of this approach is that affected industries will be able to evolve as technology improves. Under our proposed rule, we would require each MVPD to provide Service Discovery Data, Entitlement Data, and Content Delivery Data for its ``Navigable Services'' in published, transparent formats that conform to specifications set by open standards bodies. Under this proposal, we would require MVPDs to provide these Information Flows in a manner that does not restrict competitive user interfaces and features. We seek comment below on this proposed rule and on our proposed definitions of the terms (1) Service Discovery Data, (2) Entitlement Data, (3) Content Delivery Data, and (4) Open Standards Body. We base these proposed rules on three main points from the DSTAC Report related to non-security elements that we find compelling. First, we agree with the Competitive Navigation advocates that developers need the Information Flows in a standardized format to encourage development of competitive, technology-neutral solutions for competitive navigation. We also agree with the Proprietary Applications advocates, however, that providing MVPDs with flexibility, where it will not impair the competitive market, will encourage and support innovation. Significantly, consistent with a major point of agreement in the DSTAC Report, these proposed rules do not require MVPDs to ``commonly rely'' on the Information Flows for their own navigation devices, so they will not need to replace the devices that they currently provide their subscribers. We seek comment below on our proposed definitions of these three Information Flows. In particular, we seek comment on how detailed our definitions should be; that is, will standards-setting bodies define the details of what information should be in the Information Flows, sufficient to assure a commercial market for navigation systems and meet our regulatory goals? Should we define this with the same amount of detail proposed in the DSTAC Report? Are the definitions we propose appropriate for all MVPDs, or does the diversity in network architectures justify different definitions for traditional cable, satellite, and IP-based services? We propose to define Service Discovery Data as information about available Navigable Services and any instructions necessary to request a Navigable Service. We tentatively conclude that the Service Discovery Data must include, at a minimum, channel information (if any), program title, rating/parental control information, program start and stop times (or program length, for on-demand programming), and an ``Entertainment Identifier Register ID'' so that competitive navigation devices can accurately convey to consumers the programming that is available. We seek comment on whether this is the minimum amount of information that would allow a competitive navigation device developer to build a competitive system. Should this data also include information about the resolution of the program, PSIP data, and whether the program has accessibility features such as closed captions and video description? Should this data include the program description information that the MVPD sends to its own navigation devices? For example, is it necessary for the data to include descriptive information about the advertising embedded within the program? Our tentative view is that this level is detail is not necessary. Should it include capabilities of the MVPD's Navigable Services? For instance, the DSTAC Report refers to ``stream management'' as important information that conveys the number of video streams that a particular system can handle based on system bandwidth, tuner resources, or fraud prevention. One approach is that the MVPD could provide unaffiliated devices with information about the maximum number of simultaneous video streams that can be watched or recorded via the Service Discovery Data flow. We seek comment on this approach. We propose to define Entitlement Data as information about (1) which Navigable Services a subscriber has the rights to access and (2) the rights the subscriber has to use those Navigable Services. This reflects our assumption that Entitlement Data will include, at a minimum, (1) copy control information and (2) whether the content may be passed through outputs, and if so, any information pertaining to passing through outputs such as further content protection and resolution, (3) information about rights to stream the content out-of- home, (4) the resolutions that are available on various devices, and (5) recording expiration date information, if any. What additional rights information should be included in Entitlement Data? We also propose to require that this data reflect identical rights that a consumer has on Navigation Devices that the MVPD sells or leases to its subscribers. Consumers must be able to receive and use all of [[Page 14039]] content that they pay for no matter the device or application they choose, so long as that device or application protects content sufficiently. We seek comment on whether our proposed definition is flexible enough to adequately address future business models. Will consumers' rights to ``access'' content vary from their rights to ``use'' the content? For example, what if a consumer subscribes to a 4K feed of a particular channel, but the device only has content protection that is approved by the content owner to protect the high- definition feed? Will our proposed definition address that situation? How should we treat Navigable Services that can be recorded and stored remotely (i.e., ``cloud recording'' services)? Would our requirement that Entitlement Data be identical for competitive navigation devices and MVPD-provided navigation devices ensure that a subscriber could record content on a competitive navigation device if the MVPD allows subscribers to record and store that content remotely? We propose to define Content Delivery Data as data that contains the Navigable Service and any information necessary to make the Navigable Service accessible to persons with disabilities under our rules. We seek comment on this definition. Does content delivery include services other than multichannel video programming and accessibility information? For example, the DSTAC Report stated that some MVPDs provide applications that include news headlines, weather information, sports scores, and social networking. We tentatively conclude that such information is unnecessary to include in the definition of Content Delivery Data because that information is freely available from other sources on a variety of devices, whereas multichannel video programming is not. The provision of such applications may allow MVPDs and unaffiliated companies to distinguish themselves in a competitive market. In addition to the applications listed in the DSTAC Report, NCTA states that MVPDs offer services that allow subscribers ``to switch between multiple sports games or events or camera angles, view[] video-on-demand with full interactive `extras,' shopping by remote, or see[] the last channels they tuned.'' Is there anything in our proposed definition that would foreclose the possibility that a competitive navigation device could offer these services? We seek comment on this tentative conclusion. As discussed above, we propose to require MVPDs to provide the Information Flows in published, transparent formats that conform to specifications set by ``Open Standards Bodies.'' We seek comment on our proposed definition of Open Standards Body: A standards body (1) whose membership is open to consumer electronics, multichannel video programming distributors, content companies, application developers, and consumer interest organizations, (2) that has a fair balance of interested members, (3) that has a published set of procedures to assure due process, (4) that has a published appeals process, and (5) that strives to set consensus standards. We seek comment on whether these are the appropriate characteristics. Are there others we should consider? We believe that there is at least one body that meets this definition but invite commenters to provide examples of such bodies. We also believe that the characteristics listed in the definition would arm the Commission with an established test to judge whether an MVPD's method of delivering the three Information Flows is sufficient (in combination with the other elements of the proposal discussed in this item) to assure a retail market. The five characteristics that define an Open Standards Body would ensure that navigation system developers have input into the standards-setting process, give them confidence that their devices will be able to access multichannel video programming, and prevent them from needing to build a glut of ``capacities to function with a variety of types of different systems with disparate characteristics.'' We seek comment on this proposed approach. We seek comment on whether our proposal addresses the critiques of the Competitive Navigation approach that are set forth in the DSTAC Report, comments filed in response to that report, and recent ex partes. A consistent argument against the Competitive Navigation approach has been its emphasis on a required set of standards. The Commission has also been wary of stifling ``growth, innovation, and technical developments'' through regulations to implement section 629. We therefore seek comment on whether our proposed approach, which does not mandate specific standards, balances these critiques against the need for some standardization. Would this appropriately implement Congress's clear direction in section 629 to ``adopt regulations to assure the commercial availability'' of navigation devices ``in consultation with appropriate industry standard-setting organizations''? If not, how can we achieve that Congressional directive? NCTA claims that the Competitive Navigation approach would take years of lengthy standards development to implement. Competitive Navigation advocates, however, filed a set of specifications for Service Discovery Data, Entitlement Data, and Content Delivery Data, largely based on DLNA VidiPath, that they claim could achieve the Competitive Navigation proposal today. They also claim that ``any necessary standardization, if pursued in good faith, should take no more than a single year.'' We seek comment on these views. The Competitive Navigation advocates submitted evidence that DLNA has a toolkit of specifications available. Given this evidence, we propose to require MVPDs to comply with the rules two years after adoption. We seek comment on whether the standards-setting process, if pursued in good faith, could allow MVPDs to meet that proposed implementation deadline. We seek specificity on what more work needs to be done for an Open Standards Body to develop standards for Service Discovery Data, Entitlement Data, and Content Delivery Data. Given the current toolkits of specifications for Service Discovery Data, Entitlement Data, and Content Delivery Data, is it possible for us to adopt a ``fallback'' or ``safe harbor'' set of specifications? If so, should they be those proposed by the Competitive Navigation advocates, or others? We also seek comment on any other mechanisms we can adopt to ensure that MVPDs and other interested parties cooperate in prompt development of standards. The DSTAC Report includes an ``Implementation Analysis'' prepared by opponents of the Competitive Navigation approach, arguing that it does not fully establish a method for replicating, in a competitive navigation device, all of the services that an MVPD might offer. Our proposal's grant of flexibility to MVPDs gives them the opportunity to seek and adopt standards in Open Standards Bodies that will allow such replication. We seek comment on this issue. Some commenters argue that the proposal constitutes compelled speech, or interference with the manner of speech of MVPDs, and thus imperils the First Amendment rights of these speakers. The Commission does not believe that the proposed rules infringe MVPDs' First Amendment rights. The proposal to require MVPDs to provide Content Delivery Data would simply require MVPDs to provide content of their own choosing to subscribers to whom they have voluntarily agreed to [[Page 14040]] provide such content. The rules would not interfere in any way with the MVPD's choice of content or require MVPDs to provide such content to anyone to whom they have not voluntarily entered into a subscription agreement. Rather, the rules would simply allow the subscriber to access the programming that the MVPD has agreed to provide to it on any compliant Navigation Device. Thus, it does not seem that this aspect of the proposed rules infringes MVPDs' First Amendment rights. The proposal to require MVPDs to provide Service Discovery Data and Entitlement Data would require MVPDs to disclose accurate factual information concerning the Navigable Service and subscribers' rights to access it. Service Discovery Data is simply information about the Navigable Service, while Entitlement Data is information about the subscriber's rights to use the Navigable Service, designed to protect the service from unauthorized access. We believe that these proposed disclosure requirements would withstand scrutiny under the First Amendment. In general, government regulation of commercial speech will be found compatible with the First Amendment if it meets the criteria laid out in Central Hudson Gas & Electric Corp. v. Public Service Commission, 447 U.S. 557, 566 (1980): (1) There is a substantial government interest; (2) the regulation directly advances the substantial government interest; and (3) the proposed regulation is not more extensive than necessary to serve that interest. In Zauderer v. Office of Disciplinary Counsel, 471 U.S. 626, 651 (1985), the Supreme Court adopted a more relaxed standard to evaluate compelled disclosure of ``purely factual and uncontroversial'' information. Under the standard set forth in Zauderer, compelled disclosure of ``purely factual and uncontroversial'' information is permissible if ``reasonably related to the State's interest in preventing deception of consumers.'' The District of Columbia Circuit recently held in American Meat Institute v. U.S. Department of Agriculture, 760 F.3d 18 (D.C. Cir. 2014) (en banc), that government interests other than correcting deception can be invoked to sustain a disclosure requirement under Zauderer. Here, the proposed rules would require the disclosure of purely factual and uncontroversial information concerning the MVPD's service, which we believe would be sustained under the Zauderer and Circuit Court precedents because the disclosures are reasonably related to advancing the government interest in fostering competition in the market for devices used by consumers to access video programming. We have tentatively concluded that disclosure of this information is necessary to ensure that developers who are not affiliated with an MVPD can develop navigation devices that can access multichannel video programming services, so as to foster the commercial market in such devices envisioned by Congress. This is a policy that Congress directed the Commission to advance through the adoption of rules, and we propose to fulfill that statutory obligation in a manner that does not impermissibly infringe on MVPDs' First Amendment rights. We seek comment on this analysis. Finally, some commenters argue that the Competitive Navigation approach would require MVPDs to deploy ``a New Operator-Supplied Box'' to their subscribers. Other commenters disagree with this assertion, and state that the solution could be implemented in the cloud at the MVPD's discretion, thereby avoiding the need for new or additional equipment. We believe that our proposal does not require most MVPDs to develop or deploy new equipment, nor would it require subscribers to obtain additional or new equipment. In fact, our proposal may make it easier for MVPDs to offer cloud-based services because it gives each MVPD the flexibility to choose the standards that best achieve its goals. We seek comment on this belief. Would our proposal necessitate any changes to the MVPD's network, or would it give the MVPD the discretion to decide whether to modify its system architecture, as we intend? Proprietary Applications. The DSTAC's Proprietary Applications approach proposed six different methods to deliver MVPD services that would require consumers to use the MVPD's proprietary user interface. As discussed above, we have significant doubt that such an approach could assure a commercial market for navigation devices as Section 629 requires. However, we seek comment on the DSTAC's Proprietary Applications approach and whether the Proprietary Applications approach could satisfy section 629. We also seek comment on whether our proposed rules could achieve the benefits that the DSTAC Report's Proprietary Applications approach endeavors to achieve. One of the purported benefits of the Proprietary Applications approach is that it would provide MVPDs ``diversity and flexibility.'' Our proposal attempts to give MVPDs a diversity of choices and flexibility in making their Navigable Services available through competitive navigation devices, by allowing them to choose from any standard to offer the Information Flows, so long as the Information Flows are provided in a published, transparent format developed by Open Standards Bodies. Does this provide flexibility to MVPDs, while still sufficiently limiting the universe of standards such that a device could be built for a nationwide market? We seek comment on how much it would cost to build a single device that is compatible with all of the approaches listed by the Proprietary Applications advocates in the DSTAC Report. If a device were compatible with all of these Proprietary Applications approaches, would it be compatible with and able to receive all multichannel video programming services? How would this square with our statutory mandates under Sections 624A (with respect to cable operators) and 629 of the Act? Section 629 directs us to adopt regulations to assure a market for devices ``from manufacturers, retailers, and other vendors not affiliated with any multichannel video programming distributor.'' If device compatibility relies on MVPDs developing ``device specific apps,'' how could we assure entities that are not affiliated with the MVPD that their devices will be able to access multichannel video programming services? How would device manufacturers and consumers ensure that support for the application is not withdrawn by the MVPD without consultation with the device manufacturer and consumers? Do proprietary applications impose costs or certification processes that could, if left unchecked, thwart the mandates of Section 629? As an alternative to our proposal, could and should we require MVPDs to develop applications within a specific timeframe for each device manufacturer that requests such an application, and to support that application indefinitely? Section 629 also directs the Commission to adopt regulations ``in consultation with appropriate industry standard- setting organizations.'' Does this suggest that the Proprietary Applications approach proposed in the DSTAC Report, which is not entirely standards-based, is not what Congress had in mind? Are applications, as they have been deployed, ancillary to leased devices, and therefore unlikely lead to retail competition with leased devices? Are the DLNA VidiPath, RVU, DISH Virtual Joey, and Sling Media Technology Client applications ``two-device'' solutions that would require consumers to attach MVPD-provided equipment to [[Page 14041]] a separate piece of consumer-owned hardware? What standards, protocols, or specifications exist that would allow MVPDs to offer those services without any MVPD-specific equipment inside a consumer's home, or from the cloud? Could MVPDs use those standards, protocols, or specifications if we adopt our proposal? We also seek comment on any other element of the Proprietary Applications approach. Proposal Regarding Security Elements. We propose that MVPDs be required to support a content protection system that is licensable on reasonable and nondiscriminatory terms, and has a ``Trust Authority'' that is not substantially controlled by an MVPD or by the MVPD industry. We believe this approach best balances the benefits of flexibility in content protection choices by MVPDs with the need of manufacturers to choose from a limited universe of independently controlled content protection systems. Below we describe the two alternative proposals set forth by DSTAC Working Group 3, and detail the concerns raised about each by commenters. We then discuss why we believe neither approach on its own would be sufficient to meet the Commission's goals in this proceeding, and propose a ``via media'' that could allow for a competitive market for innovative retail navigation devices while also affording MVPDs significant flexibility. DSTAC Proposals. The DSTAC's Working Group 3, which focused on security, had significant points of agreement. Most fundamentally, the group agreed that downloaded security components need to remain in the control of the MVPD, but that consumer devices could not be built to simultaneously support every proprietary content protection system. Just as in the non-security context, however, DSTAC Working Group 3 had fundamental disagreements. As summarized in the DSTAC Report, Working Group 3 proposed two alternative approaches. The first is the ``HTML5'' approach, sometimes described as the ``DRM'' approach, which ``consists of MVPD/OVDs supplying media streams over HTTPS [the secure version of the protocol used to transfer data between a browser and Web site] and CE/CPE devices accessing and decrypting those media streams by supplying devices that implement the HTML5, EME, MSE and Web Crypto APIs [software permitting secure handling of the media streams by the devices].'' The most vocal advocates of the HTML5 approach are MVPDs and content providers. The second approach is the ``Media Server,'' in which ``[n]etwork security and conditional access are performed in the cloud, and the security between the cloud and retail navigation devices is a well-defined, widely used link protection mechanism such as DTCP.'' The strongest advocates of the Media Server approach are consumer electronics manufacturers and consumer-facing online service providers, as well as consumer advocates. Content protection approaches similar to both proposals are in widespread use today, in other content delivery contexts. Although there are differences in how they currently manifest, the key distinction is the way in which they allow MVPDs to control access to content--their ``conditional access'' systems. The HTML5 approach allows an MVPD to rely on any digital rights management (DRM) system that it chooses to manage its content. DRM, in this context, refers to a system of content protection that is based on permissions granted from a centralized server that the content provider (in this case, the MVPD) controls. DRM prevents subscribers from using the programming they are entitled to access in unauthorized ways. If a subscriber wishes to watch a particular program, the consumer's device contacts the rights server. If the subscriber is entitled to view, record, or otherwise utilize the content, then the rights server sends a message of approval, and the device displays the content. If the subscriber is not entitled to perform that task with the content, then the rights server sends a message of disapproval, and the device does not perform the task. Traditionally, rights servers for video are not located in consumers' homes, so they do not require additional equipment in the home. Devices like smart TVs and streaming devices that are able to play programming protected by DRM must be built to conform to each DRM, however, so not every device is equipped to handle each type of DRM employed by MVPDs and other video distributors today. Under the Media Server approach, conditional access is managed before programming enters consumer devices, and the programming is protected when moving to consumer devices by a standardized link protection system. Link protection, in this context, is an encrypted connection between a source and a receiver. The system is built on the assumption that any device that has a certificate that deems it trustworthy, granted by a trusted authority at the time of manufacture and not subsequently revoked by the Trust Authority, will treat content as instructed by copy control information embedded in data that is transmitted with content. Like DRM, link protection prevents subscribers from using the programming to which they subscribe in unauthorized ways. This technology is how a Blu-ray player sends video to a television set when physically connected--there is no additional verification step necessary, because the television has a certificate that the Blu-ray player trusts, and the television has that certificate because it was tested by the organization that controls the bestowal of certificates at manufacture to make sure that it is a secure device. The Digital Transmission Licensing Administrator (DTLA), which was founded by Intel Corporation, Hitachi, Ltd., Panasonic Corporation, Sony Corporation, and Toshiba Corporation, is an example of an organization that hands out those certificates. All of the five major Hollywood studios have approved DTLA's link-protection technology (DTCP) for protecting content as it travels from source to receiver. Traditionally, link protection has been designed to protect content within the home as it travels from one device (for example, a Blu-ray player) to another (for example, a TV set). Criticism of the DSTAC Proposals. Since publication of the DSTAC Report, commenters have raised significant and compelling concerns about universally imposing either approach in the way described by its advocates. Criticism of the HTML5 approach has come from a spectrum of commenters outside the MVPD community, but has centered on concern that MVPDs could abuse their ability to fully control the conditional access system necessary to access their content. For example, the Consumer Video Choice Coalition argues that this approach would keep control in the hands of MVPDs that ``have a history'' of using their leverage over existing application deployment to prevent ``consumers from viewing content they have paid for on the device of their choice.'' The DRM licensor could be the MVPD itself, if it chose to offer only a proprietary DRM solution, obviously posing a challenge to any device manufacturer attempting to compete. Critics of the Media Server approach have emphasized the security difficulties potentially posed by a standardized link protection system. For example, some commenters have stated that the current version of DTCP, the industry standard, is inadequate to protect 4K and ultra-high definition content. Commenters have also argued that the technical limitations on the current version of DTCP would require MVPD-provided equipment be in the home. DTLA has filed comments [[Page 14042]] responding to both of these criticisms, stating that the soon-to-be- finalized version of DTCP will be secure enough to protect the highest value content, and flexible enough to protect content delivered from the cloud. NCTA, Adobe, and ARRIS argue that, however good the link protection system, if it were industry-wide it would be a single, static point of attack that hackers could exploit, and it would be insufficiently flexible to respond to threats as they develop. NCTA argues that ``[t]oday, device manufacturers and video services can choose from a competitive marketplace of content protection technologies to stay ahead of security threats.'' In contrast, they claim, the Media Server proposal (specifically, as described in filings after the issuance of the DSTAC Report) would ``lock[] out the whole competitive market for DRM and content protection.'' The record reflects significant consensus about the importance of flexibility, though clear disagreements exist about what that should look like. Some of the strongest critiques are those that could apply equally to any approach imposed on all MVPDs and competitive navigation device manufacturers. The Commission has often been wary of mandating the adoption of specific technologies, rather than functional goals. Indeed, a number of commenters specifically warn against ``tech mandates'' in this space. Although that particular phrasing is more often heard from supporters of the HTML5 proposal, the warnings reflect a broader concern about the importance of flexibility. Public Knowledge argues that the Media Server proposal is superior because it is ``versatile and flexible,'' compared to the HTML5 proposal, which is ``too rigid technologically.'' Amazon asks us to ``approach this issue from the standpoint of giving service providers technological flexibility.'' Some commenters argue that the Commission should take no action given the lack of consensus on this issue. A stance of total inaction, however, would be an abdication of our responsibility under section 629. Without clear guidance from the Commission on the question of content protection, a truly competitive retail market for alternatives to MVPD set-top boxes is unlikely to develop. We are persuaded that the HTML5 proposal is not consistent with our goals in this proceeding. By leaving total control of security decisions to MVPDs, we would perpetuate a market in which competitors are compelled to seek permission from an MVPD in order to build devices that will work on its system. So long as MVPDs are themselves providing and profiting from navigation equipment and services, retail devices will be available only when they benefit an MVPD, not when they benefit consumers, and a truly competitive market will remain out of reach. Section 629, however, requires us to ensure that our rules do not imperil the security of the content MVPDs are carrying. At the same time, we also are not persuaded that we should require the Media Server proposal. Mandating a single shared content protection standard for every piece of MVPD content, as the Media Server proponents suggest, would create too much potential for vulnerability. It would impose no requirement (and thus, provide no guarantee) that the developer of that single shared standard develop a new, more robust version in the event of a hack. Security Proposal. Based on the record, we believe there is a middle path on the issue of content protection that can allow for a competitive market for innovative retail navigation devices, including software, that also affords MVPDs significant flexibility to protect their content, evolve their content protection, and respond to security concerns. Verimatrix asked the Commission not to ``mandate either or even both [DSTAC proposals] as `the' standard solution.'' They argued that both should be available as part of a ``toolkit'' of approaches available to MVPDs, a toolkit that could in fact include other approaches with the passage of time. We agree. We therefore propose that MVPDs retain the freedom to choose the content protection systems they support to secure their programming, so long as they enable competitive Navigation Devices. In order to do so, at least one content protection system they deploy, and to which they make available the three Information Flows in their entirety, must be ``Compliant''-- licensable on reasonable and non-discriminatory terms, and must not be controlled by MVPDs. We believe this approach will give MVPDs the flexibility they need to avoid creating a ``single point of attack'' for hackers, and the freedom to set their own pace on eliminating system-specific content security equipment in subscribers' homes, in response to the demands of the market. At the same time, we believe it will assure competitors and those considering entering the market that they can build to what is likely to be a limited number of content protection standards licensable on reasonable, non-discriminatory terms, and expect their navigation devices to work across MVPDs. They will not need to seek approval, review, or testing from the MVPDs themselves, who may have an incentive to delay or impede retail navigation devices' market entry because their leased navigation devices will remain in direct competition with the retail market for the foreseeable future. We seek comment on these assumptions. Accordingly, we propose that MVPDs must support at least one ``compliant'' conditional access system or link protection technology, although they may use others at the same time. A Compliant Security System must be licensable on reasonable, nondiscriminatory terms, and have a Trust Authority that is not substantially controlled by any MVPD or group of MVPDs. An MVPD must make available the three Information Flows in their entirety to devices using one of the Compliant Security Systems chosen by the MVPD. Such a system might include, for example, future iterations of DTCP or certain DRM systems. Commenters state that these conditional access systems could be refined to permit the full range of activity contemplated by the DSTAC, and cloud-based link protection that would minimize or eliminate the need for MVPD-provided equipment on the customer's premises. We seek comment on this proposal, including whether we need to modify our existing definition of ``conditional access'' in any way. We invite comment on some specific questions surrounding our proposal. As noted above, DTLA has stated that a pending DTCP update could fully satisfy the requirements of this proposal and the needs of MVPDs. Are there other content protection systems, particularly specific DRMs currently on the market, that are likely to be able to comply with the requirements of this approach? We recognize that this approach is likely to result in the need for competitors to support more than one Compliant Security System in their navigation devices. We believe the resulting number of Compliant Security Systems would still allow Navigation Device developers to offer competitive options, but we seek comment on this understanding. Is the term ``Trust Authority'' and our definition--``[an] entity that issues certificates and keys used by a Navigation Device to access Navigable Services that are secured by a given Compliant Security System''--sufficiently clear? Are there more accurate or descriptive terms? Should the entity that issues certificates be the same as the one that issues keys? Should the entity that licenses the Compliant Security System also be the [[Page 14043]] Trust Authority for that system? Are the proposed restrictions on the Trust Authority of a conditional access system enough to ensure its independence from MVPDs? What criteria shall we use to determine whether a Trust Authority is not ``substantially controlled'' by an MVPD or by the MVPD industry? Are there any other critical elements necessary for this proposal to both protect MVPD content and ensure a market for competitors? Will the lack of uniformity that may result from this proposal create an undue burden on competitive entities? Could an MVPD support at least one Compliant Security System but use a non-compliant content protection system on their own Navigation Devices in a manner that favors their own Navigation Devices (e.g., by selecting a Compliant Security System that is computationally burdensome for competitive devices)? Should our rules take into account differences in device, viewing location (in-home and out-of-home), and picture quality, or will our proposed ``parity'' requirement, discussed below, resolve any issues in these areas? We also seek comment on whether we should instead adopt one of the DSTAC proposals, or another alternative, as the universal standard, and how such a standard could achieve our goals of secure openness in this proceeding. If another alternative is proposed, the proponent should provide sufficient detail to compare it to the proposals set out here. We also seek comment on any other aspect of security relevant to our goals in this proceeding that we should take under consideration. Parity. We propose to require that, in implementing the security and non-security elements discussed above, MVPDs provide parity of access to content to all Navigation Devices. This will ensure that competitors have the same flexibility as MVPDs when developing and deploying devices, including applications, without restricting the ability of MVPDs to provide different subsets of content in different ways to devices in different situations. Parity will also ensure that consumers maintain full access to content they subscribe to consistent with the access prescribed in the licensing agreements between MVPDs and programmers. In order to achieve parity, we propose three requirements. First, if an MVPD makes its programming available without requiring its own equipment, such as to a tablet or smart TV application, it must make the three Information Flows available to competitive Navigation Devices without the need for MVPD-specific equipment. Second, at least one Compliant Security System chosen by the MVPD must enable access to all the programming, with all the same Entitlement Data that it carries on its equipment, and the Entitlement Data must not discriminate on the basis of the affiliation of the Navigation Device. Third, on any device on which an MVPD makes available an application to access its programming, it must support at least one Compliant Security System that offers access to the same Navigable Services with the same rights to use those Navigable Services as the MVPD affords to its own application. We discuss these proposals below. The first proposed requirement is that, if an MVPD makes available an application that allows access to its programming without the technological need for additional MVPD-specific equipment, then it shall make Service Discovery Data, Entitlement Data, and Content Delivery Data available to competitive Navigation Devices without the need for MVPD-specific equipment. For example, if an MVPD makes available an iOS or Android application that allows access to its programming, it must provide the three Information Flows to all competitive Navigation Devices without requiring the use of additional MVPD-specific equipment. The ability of competitive Navigation Devices to access content without additional equipment is a concern that has been raised repeatedly in the DSTAC proceeding. We believe that our regulations would not assure a commercial market for Navigation Devices if unaffiliated manufacturers, retailers, and other vendors need to rely on MVPD-provided equipment to receive multichannel video programming and affiliated entities do not. We seek comment on that assumption. We base this proposal on the presumption that if an MVPD can securely provide the information necessary for its proprietary application to access its programming without any additional equipment, then the MVPD should be able to provide that information to non- affiliated Navigation Devices similarly without additional equipment. We seek comment on this presumption. This proposal complements the next, in that while the entirety of the Information Flows must be available to all competitive Navigation Devices in this scenario, the specifics of how each device may use the Navigable Services depend on the relevant Entitlement Data. We recognize that DBS providers specifically will be required to have equipment of some kind in the home to deliver the three Information Flows over their one-way network, even if they also provide programming to devices connected to the Internet via other networks. How should this fact be addressed by any rule that we adopt? Are there content protection issues that are unique to DBS providers? Are there technical issues that a Navigation Device developer would need to address when developing a solution for a DBS system? We seek comment on whether we need to create a DBS exception to our proposed rule regarding proprietary applications that deliver MVPD content without the use of additional MVPD-specific equipment. We intend for this proposal to result in MVPDs serving the vast majority of non-DBS subscribers providing the Information Flows without the presence of additional MVPD-specific equipment. What technology or standards available now or in the near future will allow this ``boxless'' provision? What impact will this have on MVPD systems? Will this approach require any changes for current subscribers who do not choose to seek out a competitive Navigation Device? Given the importance of flexibility to the creation of a retail market, is this proposal correctly tailored? Would it be possible to ensure nondiscriminatory provision of the Information Flows, without requiring additional MVPD- specific equipment in the home, in another way? We seek comment on this proposal. The second proposed requirement limits an MVPD's ability to discriminate in providing the Navigable Services to competitive Navigation Devices. We propose that at least one Compliant Security System chosen by the MVPD enables access to all resolutions and formats of its Navigable Services with the same Entitlement Data to use those Navigable Services as the MVPD affords Navigation Devices that it leases, sells, or otherwise provides to its subscribers. In addition, we propose that Entitlement Data does not discriminate on the basis of the affiliation of the Navigation Device. Our proposed rule requires MVPDs to make the Information Flows fully available to any Navigation Device using the Compliant Security System they have chosen to support. Even today, however, MVPDs that provide their service to subscribers via proprietary applications on certain equipment such as mobile devices often provide only a subset of their multichannel video programming, reserving the full service for set-top boxes or other in- home viewing options. We understand that these business decisions are made for a variety of reasons, including security and contracts with content providers. We do [[Page 14044]] not believe that this practice poses a threat to the competitive market for Navigation Devices so long as it is applied in a nondiscriminatory fashion and does not interfere with the ability of competitive Navigation Device makers to develop competitive user interfaces and features. We seek comment on this view. Our intent is that each MVPD make available complete access to all purchased programming, on all channels, at all resolutions, on at least one Compliant Security System that it chooses to support. Thus, Navigation Devices accessing the three Information Flows via that Compliant Security System would have the same complete access as an MVPD's leased or provided set-top box in the home. As noted above, though, we recognize that MVPDs may make distinctions regarding the content delivered based on the use case of a device. We understand that use cases are generally differentiated based on screen size and in- or out-of-home viewing, and strength of content protection used. We seek comment on whether there are any other meaningful distinctions among use cases. We further understand that Entitlement Data enforces these distinctions in programming today, and we propose to permit MVPDs to continue to rely on Entitlement Data to draw those distinctions, so long as competitive Navigation Devices are subject to only the same restrictions as MVPD Navigation Devices. We seek comment on this proposed requirement. Does a prohibition on discrimination based on whether the Navigation Device developed is affiliated with the MVPD assure equitable treatment for similarly situated Navigation Devices? That is, will our proposed rule ensure that a competitive Navigation Device is able to access the same content with the same usage rights as a Navigation Device that the MVPD provides? The final proposed parity requirement is that, on any device on which an MVPD makes available an application to access its programming, it must support at least one Compliant Security System that offers access to the same Navigable Services with the same rights to use those Navigable Services as the MVPD affords to its own application. Our intent here is to ensure parity of access for competitive Navigation Device developers. Our proposed rules do not require MVPDs to choose Compliant Security Systems that would allow access from any device; they instead must choose one or more Compliant Security Systems to which devices can be built. It may be possible for an MVPD to abuse this flexibility, however, and choose only Compliant Security Systems that are not available on a device on which the MVPD makes available its own application to access its programming, thereby eliminating competition for access to MVPD programming via that device. The proposed rule will ensure that a competitive application can access MVPD programming on devices on which an MVPD makes available its own application, thus further ensuring a competitive market for devices including applications. We seek comment on this proposal. We seek comment on whether the three parity requirements described above, in conjunction with the other features of our proposal, will achieve the goal of ensuring a competitive retail market for Navigation Devices as contemplated by section 629. We particularly invite commenters to weigh in on the expected efficacy of these proposals, and their necessity in meeting the mandate of section 629. We are not proposing to impose a common reliance requirement; rather, we are striving to ensure equitable provision of content to competitive Navigation Devices, to the extent necessary to achieve a competitive retail market. We seek comment on this approach. Licensing and Certification. We believe that licensing and certification will play important roles under our proposed approach. MVPDs, MPAA, and companies that supply equipment to MVPDs argue that the Competitive Navigation approach could violate licensing agreements between MVPDs, content companies, and channel guide information providers. Based on our review of the DSTAC Report, the record, and the contract that CableLabs uses to license technology necessary to build a CableCARD device (DFAST), we have identified three major subject matters that pertain to licensing and certification. As set forth below, we seek comment on how licensing and certification can address (1) robustness and compliance, which ensure that content is protected as intended, (2) prevention of theft of service and harm to MVPD networks, which ensures that devices do not allow the theft of MVPD service or physically or electronically harm networks, and (3) important consumer protections in the Act and the Commission's rules. We then invite comment on alternative approaches we could take to address these issues. Compliance and Robustness. We seek comment on whether licensing can ensure adherence to copy control and other rights information (``compliance'') and adequate content protection (``robustness''). Section 629(b) states that ``[t]he Commission shall not prescribe regulations under subsection (a) of this section which would jeopardize security of multichannel video programming and other services offered over multichannel video programming systems, or impede the legal rights of a provider of such services to prevent theft of service.'' We interpret this section of the Act to require that we ensure that our regulations do not impede robustness and compliance. To achieve this statutory mandate, our regulations must ensure that Navigation Devices (1) have content protection that protects content from theft, piracy, and hacking, (2) cannot technically disrupt, impede or impair the delivery of services to an MVPD subscriber, both of which we consider to be under the umbrella of robustness (i.e., that they will adhere to robustness rules), and (3) honors the limits on the rights (including copy control limits) the subscriber has to use Navigable Services communicated in the Entitlement Information Flow (i.e., that they adhere to compliance rules). Through robustness and compliance terms, we seek to ensure that negotiated licensing terms imposed by content providers on MVPDs are passed through to Navigation Devices. Accordingly, our proposal requires MVPDs to choose Compliant Security Systems that validate only Navigation Devices that are sufficiently robust to protect content and honor the Entitlement Data that the MVPD sends to the Navigation Device. This is consistent with our understanding based on the DSTAC Report that, in other contexts, downloadable security systems usually include robustness and compliance terms as part of design audits, self-verification, or legal agreements, and that an untrustworthy actor will not be able to receive a certificate for its Navigation Devices to verify compliance. We seek comment on this proposed approach to address compliance and robustness. We also seek comment on whether we need to define the term ``robustness and compliance rules'' in our proposed definition of Compliant Security System, or if that term has a common, understood meaning, as reflected in the DSTAC Report. Should these terms include, at a minimum, what is described in the DFAST license? Should these terms contemplate protection of licensing terms between user guide information providers and MVPDs, and thus require unaffiliated Navigation Device developers to purchase their own detailed program guide information? Are there alternatives to [[Page 14045]] our proposed approach that would ensure robustness and compliance? Are there other terms from the DFAST license that we should cover in this regard? In addition to section 629, are there other sources of statutory authority for imposing these compliance and robustness requirements, such as sections 335(a) and 624A of the Act? What impact, if any, does the D.C. Circuit's decision in EchoStar Satellite L.L.C. v. FCC have on the Commission's ability to adopt compliance and robustness requirements? Protection of MVPD Networks from Harm and Theft. We also believe that a device testing and certification process is important to protect MVPDs' networks from physical or electronic harm and the potential for theft of service from devices that attach directly to the networks. We seek comment on the extent to which unaffiliated devices will attach directly to MVPD networks. If devices will connect directly to the MVPD network, is our existing rule 76.1203 sufficient to assure that those devices do not cause physical or electronic harm to the network? We do not believe that each MVPD should have its own testing and certification processes. Under the CableCARD regime, devices our rules allowed testing to be performed by a qualified test facility, which is defined as ``a testing laboratory representing cable television system operators serving a majority of the cable television subscribers in the United States or an appropriately qualified independent laboratory with adequate equipment and competent personnel knowledgeable with respect to the'' CableCARD standards. We seek comment on whether that approach protected cable networks from physical and electronic harm and from theft of service, and whether it had any effect on the commercial availability of CableCARD devices. We also seek comment on which entities have or may develop testing and certification processes. What kind of testing should be required? We note, for example, there is a seven-step certification process to ensure that DLNA-certified devices do not have defects that would harm networks. Is this type of testing sufficient? We seek comment on this proposal and any alternative approaches, such as self-certification. Consumer Protection. It is essential that any rules we adopt to meet the goals of section 629 do not undermine other important public policy goals underlying the Communications Act, which are achieved by means of requirements imposed on MVPDs. Specifically, certain commenters highlighted concerns that competitive Navigation Device developers (i) would not keep subscribers' viewing habits private, as MVPDs are required to do, (ii) would violate advertising limits during programming for children, and (iii) would build devices that do not display emergency alerts or closed captioning or enable parental controls as MVPDs are required to do. We are encouraged by the fact that retail navigation devices, such as TiVos, have been deployed in the market for over a decade without allegations of a loss of consumer privacy, violations of advertising limits during programming for children, or problems with emergency alerts and accessibility. Nonetheless, because these consumer protections are so important, we propose to require that MVPDs authenticate and provide the three Information Flows only to Navigation Devices that have been certified by the developer to meet certain public interest requirements. We tentatively conclude that this certification must state that the developer will adhere to privacy protections, pass through EAS messages, and adhere to children's programming advertising limits. This proposal would mean that MVPDs are not required to enable the Information Flows unless they receive this certification, and also that they are prohibited from providing the Navigable Services to a Navigation Device that does not have such a certification. MVPDs cannot withhold the three Information Flows if they have received such certification and do not have a good faith reason to doubt its validity. This will ensure that the public policy goals underlying these requirements are met regardless of which device a consumer chooses to access multichannel video programming. We seek comment on this proposal and invite alternative proposals within our jurisdiction that would ensure that these important consumer protections remain in effect while we promote a competitive navigation market. Should the proposed certification address any other issues, including compliance with the Commission's accessibility rules and parental controls, or should we leave these matters to the market? We also seek comment on whether the retail market will be competitive enough to make any such regulation unnecessary (that is, the competitive market will assure that the protections that consumers desire are adequately protected). We seek comment on the best way to implement such a certification process. Should this be a self-certification process, or are there viable alternatives to self-certification? For example, should there be an independent entity that validates the competitor's certification? Should we develop a standardized form? Who would be responsible for maintaining a record of the certification? Could Open Standards Bodies or some other third-party entity require certification as part of their regimes and maintain those records? Alternatively, should the Commission maintain a repository of certifications? In addition, if there are lapses in compliance with any certification, what would be the appropriate enforcement mechanism? With respect to all MVPDs, we believe that Section 629 of the Act provides authority to impose these restrictions, because consumers may be dissuaded from opting for a competitive navigation solution if they are not confident that their interests will be protected to the same extent as in an MVPD-provided solution. With respect to DBS operators, we also believe section 335(a)--which directs the Commission to ``impose, on providers of direct broadcast satellite service, public interest or other requirements for providing video programming''-- grants us authority to ensure that these goals are met regardless of whether the DBS multichannel video programming is accessed by means of a DBS-provided device. We also seek comment on whether the sources of statutory authority for imposing on MVPDs privacy requirements, advertising limits on children's programming, emergency alerting requirements, closed captioning requirements, video description requirements, parental control requirements, or other consumer protection requirements also authorize the Commission to require that MVPDs provide the three Information Flows only to Navigation Devices that have been certified by the developer to meet certain public interest requirements. This will ensure that the new Navigation Device rules will not undercut our rules imposing those public interest requirements. We seek comment on these views and invite commenters to suggest any other sources of authority. We seek comment on how MVPDs could ensure that they do not provide the Information Flows to uncertified devices. Could the MVPD use device authentication to ensure that they do not send the three Information Flows to uncertified Navigation Devices? Could the Entitlement Data direct a device not to display the Content Data unless the Navigation Device was built by a developer who is certified? Are there [[Page 14046]] other methods MVPDs could use to ensure that they send the Information Flows only to Navigation Devices that will honor these important consumer protection obligations? Similarly, how can MVPDs ensure, as both a technical and practical matter, that the Information Flows are no longer provided if there are any lapses in a competitor's compliance with these obligations? We seek comment on how this requirement will affect Navigation Device developers. We do not expect it will be difficult for developers to certify to these consumer protections. For example, such content as EAS alerts will be included in the Information Flows that MVPDs make available, and we do not expect enabling receipt of this content to be burdensome. Similarly, as to ensuring the privacy of subscriber information, given the national market for consumer technology, they must already ensure that their products and services meet the privacy standards of the strictest state regulatory regime. Moreover, the global economy means that many developers must comply with the European Union privacy regulations, which are much more stringent that the requirements placed on MVPDs under sections 631 and 338 of the Communications Act. Although we propose that competitive device manufacturers certify compliance with sections 631 and 338, we seek comment on the extent to which those manufacturers that collect personally identifiable information from consumers using their devices are currently subject to state privacy laws and the scope of any such laws. We note, for example, that California's Online Privacy Protection Act applies to an entity that owns an online service that collects and maintains personally identifiable information from consumers residing in California who use the online service if the online service is used for commercial purposes. Would this statute apply to competitive device manufacturers to the extent that they use the Internet to provide programming guide, scheduling, and recording information to consumers? Are there similar state privacy laws covering consumers residing in each of the other states? To what extent do state privacy laws require that manufacturers have privacy policies? MVPDs are obligated to provide privacy protections under sections 631 and 338 of the Act. Do state privacy laws require manufacturers to provide a comparable level of consumer protection? For example, the privacy protections established by sections 631 and 338 are enforceable by both the Commission and by private rights of action. Do any state laws provide for both administrative and private rights of action and/or damages in the event of a privacy violation? TiVo asserts that it is subject to enforcement by the FTC and state regulators for any failures to abide by its comprehensive privacy policy. We note that the FTC has taken legal action under its broad Section 5 ``unfair and deceptive acts'' authority against companies that violate their posted consumer privacy policies. We seek comment on whether state laws governing unfair and deceptive acts have similarly been used against companies that violate their consumer privacy policies and whether these laws are applicable to competitive device manufacturers. Furthermore, the Video Privacy Protection Act, with limited exceptions, generally prohibits companies that provide video online from disclosing the viewing history and other personally identifiable information of a consumer without the consumer's prior written consent. Does this statute impose any obligations on competitive device manufacturers to protect personally identifiable information collected from consumers? Are there any other state or federal laws that would help to ensure that competitive device manufacturers protect consumer privacy? Licensing Alternatives. As an alternative to the licensing and certification approaches we lay out above, should we instead require industry parties to develop a standardized license and certification regime, similar to the DFAST license, which has appeared to work at balancing consumer protection issues and allowing retail Navigation Device developers to innovate? Who would be responsible for managing that licensing system? Should our Navigation Device rules instead impose these terms by regulation, either initially or if industry parties cannot reach agreement? Does the Commission have authority to impose such terms via regulation? Has competitive navigation under the CableCARD regime led to any license agreement violations, privacy violations, or other violations of consumer protection laws? If so, what were the specifics of those violations, and how were they resolved? We do not currently have evidence that regulations are needed to address concerns raised by MVPDs and content providers that competitive navigation solutions will disrupt elements of service presentation (such as agreed-upon channel lineups and neighborhoods), replace or alter advertising, or improperly manipulate content. We have not seen evidence of any such problems in the CableCARD regime, and do not expect that the new approach we propose above will allow such behavior. Accordingly, we believe these concerns are speculative, and while we believe at this time it is unnecessary for us to propose any rules to address these issues, we seek comment on this view. We also seek comment on the extent to which copyright law may protect against these concerns, and note that nothing in our proposal will change or affect content creators' rights or remedies under copyright law. In the event that commenters submit evidence indicating that regulations are needed, we seek comment on whether we have the authority and enforcement mechanisms to address such concerns. Small MVPDs. We seek comment on how any rules that we adopt could affect small MVPDs, and whether we should impose different rules or implementation deadlines for small MVPDs. We tentatively conclude that all analog cable systems should be exempt from the rules we propose today, just as they were exempt from the original separation of security rules. We also seek specific comment on the American Cable Association's proposal to exempt MVPDs serving one million or fewer subscribers from any rules we adopt. Is there a size-neutral way that we could ensure that our rules are not overly burdensome to MVPDs? The American Cable Association also asserts that many of its members are not prepared to transition soon to delivery of their services in Internet Protocol, but we note that our proposed rules do not require MVPDs to use Internet Protocol to deliver the three Information Flows or Compliant Security System. For example, although we do not advocate reliance on CableCARD as a long-term solution, we note that the CableCARD standard largely appears to align with our proposed rules. Could the CableCARD regime remain a viable option for achieving the goals of Section 629 for those systems that continue to use QAM technology? Are there any changes to the CableCARD rules that should be made in light of more than a decade of experience with the regime or to accommodate changes in the MVPD industry since the rules were adopted? Do MVPDs who have not transitioned to IP delivery of control channel information nonetheless provide IP-based applications to their customers or use IP to send content to devices throughout a home network? If so, should such MVPDs be required to comply with the rules requiring parity [[Page 14047]] for other Navigation Device developers via the Information Flows? Billing Transparency. We seek comment on how best to align our existing rule on separate billing and subsidies for devices with the text of the Act, the current state of the marketplace, and our goal of facilitating a competitive marketplace for navigation devices. Section 629 states that our regulations ``shall not prohibit [MVPDs] from also offering [navigation devices] to consumers, if the system operator's charges to consumers for such devices and equipment are separately stated and not subsidized by charges for any such service.'' We note that, although Section 629(a) of the Act states that the Commission ``shall not prohibit'' any MVPD from offering navigation devices to consumers if the equipment charges are separately stated and not subsidized by service charges, it does not appear to affirmatively require the Commission to require separate statement or to prohibit cross-subsidies. In the Commission's 1998 Report and Order, which implemented section 629, the Commission rejected the argument that section 629's requirements are ``absolute'' and that the section ``expressly prevents all MVPDs from subsidizing equipment cost with service charges.'' The Commission found that in a competitive market ``there is minimal concern with below cost pricing because revenues do not emanate from monopoly profits. The subsidy provides a means to expand products and services, and the market provides a self- correcting resolution of the subsidy.'' The Commission thus concluded that ``[e]xisting equipment rate rules applicable to cable television systems not facing effective competition address Section 629(a)'s requirement that charges to consumers for such devices and equipment are separately stated and not subsidized by charges for any other service.'' Accordingly, the Commission applied the separate billing and anti-subsidy requirements set forth in Section 76.1206 of our rules only to rate-regulated cable operators. In 2010, the Commission adopted ``CableCARD support'' rules, which included pricing transparency requirements and required uniform pricing for CableCARDs ``regardless of whether the CableCARD is used in a leased set-top box or a navigation device purchased at retail.'' Developments since the 1998 Report and Order raise a question whether the applicability of the Act's rate regulation provisions should continue to determine the applicability of our separate billing and anti-subsidy rules. At the time of that order, only a small minority of cable systems had been determined to be subject to ``effective competition'' as defined in the rate regulation provisions of the Act and thus exempted from rate regulation. Since that time, the Commission has made many findings that the statutory test for effective competition was met and updated its effective competition rules to reflect the current MVPD marketplace. We are no longer convinced that the statutory test for the applicability of rate regulation properly addresses our objective of promoting a competitive market for navigation devices as directed by Section 629. We base this proposed change in policy on our belief that customers may likely consider the costs of lease against purchase when considering whether to purchase a competitively provided device, and must know what it costs to lease a device in order to make an informed decision. Accordingly, we seek comment on whether we should modify our billing and/or anti-subsidy requirements set forth in section 76.1206. In particular, under the circumstances that exist today, should we revise our rules to require all MVPDs to state separately a charge for leased navigation devices and to reduce their charges by that amount to customers who provide their own devices, regardless of whether the statutory test for the applicability of rate regulation is met? Is such a requirement a necessary or appropriate complement to the rules we propose today to facilitate the offering of competitive navigation devices? We tentatively conclude that we should adopt such a requirement with respect to all navigation devices, including modems, routers, and set top boxes, and we invite comment on that tentative conclusion. If we adopt a requirement that all MVPDs state separately a charge for leased navigation devices, we invite comment on whether we should also impose a prohibition on cross-subsidization of device charges with service fees. Section 629 discusses separate statement and prohibition of cross-subsidy in the same sentence; but we read the statute to permit us to make an individual determination whether to impose one requirement or the other, or both (or neither). Do present market circumstances warrant adoption of an anti-subsidization rule? Observers often suggest that the charges currently imposed for leased devices are typically excessive, rather than cross-subsidized. A requirement of separate statement, by itself, should help to enable competition in the marketplace to ameliorate excessive pricing of leased devices. Is it therefore unnecessary at this time for us to adopt an expanded rule against cross-subsidization? Or would such a rule provide a useful prophylactic against future attempts to cross-subsidize? Would it suffice to require that a nonzero price be identified for any leased device? We seek comment on these issues. Commenters supporting adoption of an expanded anti-cross-subsidization rule should address the Commission's previous determination that ``[a]pplying the subsidy prohibition to all MVPDs would lead to distortions in the market, stifling innovation and undermining consumer choice.'' If we decide to adopt an updated anti-subsidy rule, how should we determine whether a device fee is cross-subsidized? For example, would the factors set forth in section 76.1205(b)(5) for determining the price that is ``reasonably allocable'' to a device lease fee be applicable for this purpose? How should we consider the possibility that an MVPD would ascribe a zero or near-zero price to a navigation device, and what implications might there be for further Commission responsibilities and actions? Are there other ways in which we can promote a competitive marketplace through requirements applicable to equipment that MVPDs lease, sell, or otherwise provide to their subscribers? For example, Anne Arundel and Montgomery Counties, Maryland in their reply comments propose that our rules (1) prohibit service charges for viewing on more than one device, (2) prohibit service charge penalties for consumer-owned devices, (3) prohibit multi-year contracts based on the use of a consumer-owned device, (4) ban ``additional outlet'' fees, (5) prohibit requirements that consumers lease equipment, and (6) give consumers the ability to purchase equipment outright. Commenters should include a discussion of the Commission's authority to adopt any regulations proposed. CableCARD Support and Reporting. In this section, we seek comment on whether the CableCARD consumer support rules set forth in section 76.1205(b) of the Commission's rules continue to serve a useful purpose and should be retained following the D.C. Circuit's 2013 decision in EchoStar Satellite L.L.C. v. FCC, which vacated two 2003 Commission Orders adopting the CableCARD standard as the method that must be used by digital cable operators in implementing the separation of security requirement for navigation devices. We tentatively conclude that these rules continue to serve a useful purpose and propose to retain them in our rules. We seek [[Page 14048]] comment on this tentative conclusion. Alternatively, if commenters contend that the CableCARD consumer support rules should be eliminated or modified in light of EchoStar, commenters should explain the basis for their contention. To the extent that we conclude that the CableCARD consumer support rules continue to serve a useful purpose, we seek comment on whether to eliminate the requirement that the six largest cable operators submit status reports to the Commission every 90 days on CableCARD deployment and support. In 2005, the Commission adopted a requirement that the six largest cable operators submit status reports to the Commission every 90 days on CableCARD deployment and support. The Commission adopted this reporting requirement to ensure that cable operators meet their obligations to deploy and support CableCARDs. In an effort to ``improve consumers' experience with retail navigation devices,'' the Commission in 2010 imposed specific CableCARD consumer support requirements on cable operators. Specifically, these CableCARD consumer support rules: (1) Require cable operators to support the reception of switched digital video services on retail devices to ensure that subscribers are able to access the services for which they pay regardless of whether they lease or purchase their devices; (2) prohibit price discrimination against retail devices to support a competitive marketplace for retail devices; (3) require cable operators to allow self-installation of CableCARDs where device manufacturers offer device-specific installation instructions to make the installation experience for retail devices comparable to the experience for leased devices; (4) require cable operators to provide multi-stream CableCARDs by default to ensure that cable operators are providing their subscribers with current CableCARD technology; and (5) clarify that CableCARD device certification rules are limited to certain technical features to make it easier for device manufacturers to get their products to market. In 2013, the D.C. Circuit in EchoStar vacated the two 2003 Orders adopting the CableCARD standard as the method that must be used by all MVPDs in implementing the separation of security requirement for navigation devices. The D.C. Circuit concluded that the Commission lacked the authority under section 629 to impose encoding rules, which put a ceiling on the copy protections that MVPDs can impose, on satellite carriers. The Commission argued that those rules were not severable from the rest of the rules adopted in the 2003 Orders (including the rule that imposes the CableCARD standard), and therefore the D.C. Circuit vacated both of the orders. Subsequently, questions have been raised as to what effect, if any, the EchoStar decision has on the continued validity of the CableCARD consumer support requirements in Section 76.1205(b) of the Commission's rules. We seek comment on whether the CableCARD consumer support rules set forth in Section 76.1205(b) continue to serve a useful purpose after the D.C. Circuit's 2013 decision in EchoStar. As discussed above, the EchoStar decision vacated the two 2003 Orders that adopted rules mandating that MVPDs use the CableCARD standard to support the separation of security requirement. The EchoStar decision did not, however, vacate or even address the consumer support rules for cable operators that choose to continue to rely on the CableCARD standard in order to comply with the separated security requirement, which remains in effect. Accordingly, we believe that the consumer support rules set forth in section 76.1205(b) continue to serve a useful purpose and should be retained. We seek comment on this belief. Are the consumer support rules still necessary to support a competitive market for retail navigation devices? Additionally, we seek comment on whether to eliminate the CableCARD reporting requirement applicable to the six largest cable operators. Specifically, we seek comment on whether the reporting requirement is still necessary in light of the CableCARD consumer support requirements, as well as the recent repeal of the integration ban. As explained above, the reporting requirement was intended to ensure that cable operators satisfy their obligations to deploy and support CableCARDs. Are the consumer support requirements sufficient to ensure that cable operators meet these obligations? If so, is there any reason to retain the reporting requirement or should it be eliminated? Initial Regulatory Flexibility Act Analysis. As required by the Regulatory Flexibility Act of 1980, as amended (``RFA'') the Commission has prepared this present Initial Regulatory Flexibility Analysis (``IRFA'') concerning the possible significant economic impact on small entities by the policies and rules proposed in this Notice of Proposed Rulemaking (Notice). Written public comments are requested on this IRFA. Comments must be identified as responses to the IRFA and must be filed by the deadlines for comments indicated on the first page of the Notice. The Commission will send a copy of the Notice, including this IRFA, to the Chief Counsel for Advocacy of the Small Business Administration (SBA). In addition, the Notice and IRFA (or summaries thereof) will be published in the Federal Register. Need for and Objectives of the Proposed Rules. In the Notice, the Commission seeks comment on proposed rules relating to the Commission's obligation under Section 629 of the Communications Act to assure a commercial market for equipment that can access multichannel video programming and other services offered over multichannel video programming systems. The NPRM tentatively concludes that new rules about multichannel video programming distributor's (MVPD's) provision of content are needed to further the goals of Section 629. It proposes such new rules, relating to the information that MVPDs must provide to allow competitive user interfaces, the security flexibility necessary to protect content, and the parity requirements necessary to ensure a level playing field between MVPD-leased equipment and competitive methods that consumers might use to access MVPD service instead of leasing MVPD equipment. The Notice also asks about MVPD fees for devices and the current status of the Commission's CableCARD rules, the existing rules arising from Section 629. Legal Basis. The authority for the action proposed in this rulemaking is contained in sections 1, 4, 303, 303A, 335, 403, 624, 624A, 629, 631, 706, and 713 of the Communications Act of 1934, as amended, 47 U.S.C. 151, 154, 303, 303a, 335, 403, 544, 544a, 549, 551, 606, and 613. Description and Estimate of the Number of Small Entities to Which the Proposed Rules Will Apply. The RFA directs the Commission to provide a description of and, where feasible, an estimate of the number of small entities that will be affected by the proposed rules, if adopted. The RFA generally defines the term ``small entity'' as having the same meaning as the terms ``small business,'' small organization,'' and ``small government jurisdiction.'' In addition, the term ``small business'' has the same meaning as the term ``small business concern'' under the Small Business Act. A small business concern is one which: (1) Is independently owned and operated; (2) is not dominant in its field of operation; and (3) satisfies any additional criteria established by the SBA. Wired Telecommunications Carriers. The North American Industry Classification System (``NAICS'') defines [[Page 14049]] ``Wired Telecommunications Carriers'' as follows: ``This industry comprises establishments primarily engaged in operating and/or providing access to transmission facilities and infrastructure that they own and/or lease for the transmission of voice, data, text, sound, and video using wired telecommunications networks. Transmission facilities may be based on a single technology or a combination of technologies. Establishments in this industry use the wired telecommunications network facilities that they operate to provide a variety of services, such as wired telephony services, including VoIP services; wired (cable) audio and video programming distribution; and wired broadband Internet services. By exception, establishments providing satellite television distribution services using facilities and infrastructure that they operate are included in this industry.'' The SBA has developed a small business size standard for wireline firms for the broad economic census category of ``Wired Telecommunications Carriers.'' Under this category, a wireline business is small if it has 1,500 or fewer employees. Census data for 2007 shows that there were 3,188 firms that operated for the entire year. Of this total, 3,144 firms had fewer than 1,000 employees, and 44 firms had 1,000 or more employees. Therefore, under this size standard, we estimate that the majority of businesses can be considered small entities. Cable Television Distribution Services. Since 2007, these services have been defined within the broad economic census category of Wired Telecommunications Carriers, which category is defined above. The SBA has developed a small business size standard for this category, which is: All such businesses having 1,500 or fewer employees. Census data for 2007 shows that there were 3,188 firms that operated for the entire year. Of this total, 3,144 firms had fewer than 1,000 employees, and 44 firms had 1,000 or more employees. Therefore, under this size standard, we estimate that the majority of businesses can be considered small entities. Cable Companies and Systems. The Commission has developed its own small business size standards for the purpose of cable rate regulation. Under the Commission's rules, a ``small cable company'' is one serving 400,000 or fewer subscribers nationwide. Industry data shows that there are currently 660 cable operators. Of this total, all but ten cable operators nationwide are small under this size standard. In addition, under the Commission's rate regulation rules, a ``small system'' is a cable system serving 15,000 or fewer subscribers. Current Commission records show 4,629 cable systems nationwide. Of this total, 4,057 cable systems have less than 20,000 subscribers, and 572 systems have 20,000 or more subscribers, based on the same records. Thus, under this standard, we estimate that most cable systems are small entities. Cable System Operators (Telecom Act Standard). The Communications Act of 1934, as amended, also contains a size standard for small cable system operators, which is ``a cable operator that, directly or through an affiliate, serves in the aggregate fewer than 1 percent of all subscribers in the United States and is not affiliated with any entity or entities whose gross annual revenues in the aggregate exceed $250,000,000.'' There are approximately 54 million cable video subscribers in the United States today. Accordingly, an operator serving fewer than 540,000 subscribers shall be deemed a small operator if its annual revenues, when combined with the total annual revenues of all its affiliates, do not exceed $250 million in the aggregate. Based on available data, we find that all but ten incumbent cable operators are small entities under this size standard. We note that the Commission neither requests nor collects information on whether cable system operators are affiliated with entities whose gross annual revenues exceed $250 million. Although it seems certain that some of these cable system operators are affiliated with entities whose gross annual revenues exceed $250,000,000, we are unable at this time to estimate with greater precision the number of cable system operators that would qualify as small cable operators under the definition in the Communications Act. Direct Broadcast Satellite (DBS) Service. DBS service is a nationally distributed subscription service that delivers video and audio programming via satellite to a small parabolic ``dish'' antenna at the subscriber's location. DBS, by exception, is now included in the SBA's broad economic census category, Wired Telecommunications Carriers, which was developed for small wireline businesses. Under this category, the SBA deems a wireline business to be small if it has 1,500 or fewer employees. Census data for 2007 shows that there were 3,188 firms that operated for that entire year. Of this total, 2,940 firms had fewer than 100 employees, and 248 firms had 100 or more employees. Therefore, under this size standard, the majority of such businesses can be considered small entities. However, the data we have available as a basis for estimating the number of such small entities were gathered under a superseded SBA small business size standard formerly titled ``Cable and Other Program Distribution.'' As of 2002, the SBA defined a small Cable and Other Program Distribution provider as one with $12.5 million or less in annual receipts. Currently, only two entities provide DBS service, which requires a great investment of capital for operation: DIRECTV and DISH Network. Each currently offers subscription services. DIRECTV and DISH Network each report annual revenues that are in excess of the threshold for a small business. Because DBS service requires significant capital, we believe it is unlikely that a small entity as defined under the superseded SBA size standard would have the financial wherewithal to become a DBS service provider. Description of Projected Reporting, Recordkeeping and Other Compliance Requirements. The Notice proposes the following new or revised reporting or recordkeeping requirements. It proposes that MVPDs offer three flows of information using any published, transparent format that conforms to specifications set by open standards bodies, to permit the development of competitive navigation devices with competitive user interfaces. It proposes that the flows of information not be made available to a device absent verification that the device will honor copying and recording limits, privacy, Emergency Alert System messages, the Accessibility Rules in Part 79 of the Commission's Rules, parental control information, and children's programming advertising limits. It further proposes that each MVPD use at least one content protection system that is licensed on a reasonable and non- discriminatory basis by an organization that is not affiliated with MVPDs; that at least one such content protection system make available the entirety of the MVPD's service; and that the MVPD ensure that, on any device for which it provides an application, such a content protection system is available to competitors wishing to provide the same level of service. It also proposes a bar on Entitlement data discrimination because of the affiliation of otherwise proper devices. The Notice proposes to require each MVPD that offers its own application on unaffiliated devices without the need for MVPD-specific equipment to also offer the three information flows to unaffiliated applications without the need for MVPD-specific equipment. [[Page 14050]] Finally, the Notice proposes to require MVPDs to separately state the fees charged to lease devices on consumers' bills, and, in a possible reduction of reporting requirements, seeks comment on discontinuing a requirement that the six largest cable operators report to the Commission about their support for CableCARD. Steps Taken To Minimize Significant Impact on Small Entities, and Significant Alternatives Considered. The RFA requires an agency to describe any significant alternatives that it has considered in reaching its proposed approach, which may include the following four alternatives (among others): (1) The establishment of differing compliance or reporting requirements or timetables that take into account the resources available to small entities; (2) the clarification, consolidation, or simplification of compliance or reporting requirements under the rule for small entities; (3) the use of performance, rather than design, standards; and (4) an exemption from coverage of the rule, or any part thereof, for small entities. The Notice proposes rules intended to assure a commercial market for competitive Navigation Devices. The Commission's has a statutory obligation to do so, and has concluded that it cannot do so if competitive Navigation Devices are tied to specific MVPDs. As a result, the compliance requirements must be the same for all MVPDs, large and small. The rules have been proposed in terms to minimize economic impact on small entities. The proposed rules allow flexibility for MVPDs while still assuring device manufacturers they can build to a manageable number of standards, and assuring consumers that they only need a single device. That flexibility arises from the fact that the proposed rules establish performance standards, not design standards. Although the compliance requirements must be the same in order to comply with our statutory mandate, the requirements themselves are clear and simple. Because they would be able, under the proposed rules, to rely on open standards for information flows and RAND licensable security, small MVPDs would not have to engage in complex compliance efforts. The only reporting requirements are related to fees for device leases, which cannot be further simplified for small entities. Finally, although the rules do not contemplate exemptions for small entities, the proposed rule requiring ``boxless' provision of the three information flows applies only to MVPDs with the technological sophistication to offer ``boxless'' programming to their own devices. Thus, smaller MVPDs that are not providing this service will not be required to implement ``boxless'' information flows by operation of the proposed rule. Federal Rules Which Duplicate, Overlap, or Conflict With the Commission's Proposals. None. Authority. This Notice of Proposed Rulemaking is issued pursuant to authority contained in Sections 4(i), 4(j), 303(r), 325, 403, 616, 628, 629, 634 and 713 of the Communications Act of 1934, as amended, 47 U.S.C. 154(i), 154(j), 303(r), 325, 403, 536, 548, 549, 554, and 613. Ex Parte Rules. The proceeding initiated by this Notice of Proposed Rulemaking shall be treated as ``permit-but-disclose'' proceedings in accordance with the Commission's ex parte rules. Persons making ex parte presentations must file a copy of any written presentation or a memorandum summarizing any oral presentation within two business days after the presentation (unless a different deadline applicable to the Sunshine period applies). Persons making oral ex parte presentations are reminded that memoranda summarizing the presentation must: (1) List all persons attending or otherwise participating in the meeting at which the ex parte presentation was made; and (2) summarize all data presented and arguments made during the presentation. If the presentation consisted in whole or in part of the presentation of data or arguments already reflected in the presenter's written comments, memoranda, or other filings in the proceeding, the presenter may provide citations to such data or arguments in his or her prior comments, memoranda, or other filings (specifying the relevant page and/or paragraph numbers where such data or arguments can be found) in lieu of summarizing them in the memorandum. Documents shown or given to Commission staff during ex parte meetings are deemed to be written ex parte presentations and must be filed consistent with rule 1.1206(b). In proceedings governed by rule 1.49(f) or for which the Commission has made available a method of electronic filing, written ex parte presentations and memoranda summarizing oral ex parte presentations, and all attachments thereto, must be filed through the electronic comment filing system available for that proceeding, and must be filed in their native format (e.g., .doc, .xml, .ppt, searchable .pdf). Participants in this proceeding should familiarize themselves with the Commission's ex parte rules. Filing Requirements. Pursuant to sections 1.415 and 1.419 of the Commission's rules,\1\ interested parties may file comments and reply comments on or before the dates indicated on the first page of this document. Comments may be filed using the Commission's Electronic Comment Filing System (``ECFS'').\2\ --------------------------------------------------------------------------- \1\ See id. Sec. Sec. 1.415, 1.419. \2\ See Electronic Filing of Documents in Rulemaking Proceedings, 63 FR 24121 (1998). --------------------------------------------------------------------------- Electronic Filers: Comments may be filed electronically using the Internet by accessing the ECFS: http://fjallfoss.fcc.gov/ecfs2/. Paper Filers: Parties who choose to file by paper must file an original and one copy of each filing. If more than one docket or rulemaking number appears in the caption of this proceeding, filers must submit two additional copies for each additional docket or rulemaking number. Filings can be sent by hand or messenger delivery, by commercial overnight courier, or by first-class or overnight U.S. Postal Service mail. All filings must be addressed to the Commission's Secretary, Office of the Secretary, Federal Communications Commission. All hand-delivered or messenger-delivered paper filings for the Commission's Secretary must be delivered to FCC Headquarters at 445 12th St. SW., Room TW-A325, Washington, DC 20554. The filing hours are 8:00 a.m. to 7:00 p.m. All hand deliveries must be held together with rubber bands or fasteners. Any envelopes and boxes must be disposed of before entering the building. Commercial overnight mail (other than U.S. Postal Service Express Mail and Priority Mail) must be sent to 9300 East Hampton Drive, Capitol Heights, MD 20743. U.S. Postal Service first-class, Express, and Priority mail must be addressed to 445 12th Street SW., Washington, DC 20554. Availability of Documents. Comments and reply comments will be available for public inspection during regular business hours in the FCC Reference Center, Federal Communications Commission, 445 12th Street SW., CY-A257, Washington, DC 20554. These documents will also be available via ECFS. Documents will be available electronically in ASCII, Microsoft Word, and/or Adobe Acrobat. People with Disabilities. To request materials in accessible formats for people with disabilities (braille, large [[Page 14051]] print, electronic files, audio format), send an email to [email protected] or call the FCC's Consumer and Governmental Affairs Bureau at (202) 418-0530 (voice), (202) 418-0432 (TTY). Additional Information. For additional information on this proceeding, contact Brendan Murray of the Media Bureau, Policy Division, (202) 418-1573 or Lyle Elder of the Media Bureau, Policy Division, (202) 418-2365. Regulatory Flexibility Analysis. As required by the Regulatory Flexibility Act of 1980, see 5 U.S.C. 604, the Commission has prepared an Initial Regulatory Flexibility Analysis (IRFA) of the possible significant economic impact on small entities of the policies and rules addressed in this document. The IRFA is set forth in Appendix B. Written public comments are requested in the IRFA. These comments must be filed in accordance with the same filing deadlines as comments filed in response to this Notice of Proposed Rulemaking as set forth on the first page of this document, and have a separate and distinct heading designating them as responses to the IRFA. Initial Paperwork Reduction Act Analysis. This Notice of Proposed Rulemaking seeks comment on a potential new or revised information collection requirement. If the Commission adopts any new or revised information collection requirement, the Commission will publish a separate notice in the Federal Register inviting the public to comment on the requirement, as required by the Paperwork Reduction Act of 1995, Public Law 104-13 (44 U.S.C. 3501-3520). In addition, pursuant to the Small Business Paperwork Relief Act of 2002, Public Law 107-198, 44 U.S.C. 3506(c)(4), the Commission seeks specific comment on how it might ``further reduce the information collection burden for small business concerns with fewer than 25 employees.'' Ordering Clauses. Accordingly, it is ordered, pursuant to the authority contained in Sections 4(i), 4(j), 303, 303A, 335, 403, 624, 624A, 629, 631, 706, and 713 of the Communications Act of 1934, as amended, 47 U.S.C. 154(i), 154(j), 303, 303a, 335, 403, 544, 544a, 549, 551, 606, and 613, that this Notice of Proposed Rulemaking and Memorandum Opinion and Order is adopted. It is further ordered that the Commission's Consumer and Governmental Affairs Bureau, Reference Information Center, shall send a copy of this Notice of Proposed Rulemaking and Memorandum Opinion and Order including the Regulatory Flexibility Analysis, to the Chief Counsel for Advocacy of the Small Business Administration. List of Subjects in 47 CFR Part 76 Administrative practice and procedure; Cable television; Equal employment opportunity; Political candidates; Reporting and recordkeeping requirements. Federal Communications Commission. Marlene H. Dortch, Secretary. Proposed Rules For the reasons discussed in the preamble, the Federal Communications Commission proposes to amend 47 CFR part 76 as follows: * * * * * PART 76--MULTICHANNEL VIDEO AND CABLE TELEVISION SERVICE 0 1. The authority citation for part 76 continues to read as follows: Authority: 47 U.S.C. 151, 152, 153, 154, 301, 302, 302a, 303, 303a, 307, 308, 309, 312, 315, 317, 325, 338, 339, 340, 341, 503, 521, 522, 531, 532, 534, 535, 536, 537, 543, 544, 544a, 545, 548, 549, 552, 554, 556, 558, 560, 561, 571, 572, 573. 0 2. Amend Sec. 76.1200 by revising paragraphs (a) through (e) and adding new paragraphs (f) through (m)to read as follows: Sec. 76.1200 Definitions. (a) Affiliate. A person or entity that (directly or indirectly) owns or controls, is owned or controlled by, or is under common ownership or control with, another person, as defined in the notes accompanying Sec. 76.501. (b) Certificate. A document that certifies that a Navigation Device will honor privacy, Emergency Alert System messages, the Accessibility Rules in part 79 of this Chapter, parental control information, and children's programming advertising limits. (c) Compliant Security System. A conditional access system or link protection technology that: (1) Is licensable on reasonable and nondiscriminatory terms; (2) relies on a Trust Authority not substantially controlled by any multichannel video programming distributor or group of multichannel video programming distributors; and (3) is licensable on terms that require licensees to comply with robustness and compliance rules. (d) Conditional access. The mechanisms that provide for selective access and denial of specific services and make use of signal security that can prevent a signal from being received except by authorized users. (e) Content Delivery Data. Data that contains the Navigable Service and any information necessary to make the Navigable Service accessible to persons with disabilities under part 79 of this Title. (f) Entitlement Data. Information about (1) which Navigable Services a subscriber has the rights to access and (2) the rights the subscriber has to use those Navigable Services. Entitlement data shall reflect identical rights that a consumer has on Navigation Devices that the multichannel video programming distributor sells or leases to its subscribers. (g) Multichannel video programming distributor. A person such as, but not limited to, a cable operator, a BRS/EBS provider, a direct broadcast satellite service, or a television receive-only satellite program distributor, who owns or operates a multichannel video programming system. (h) Multichannel video programming system. A distribution system that makes available for purchase, by customers or subscribers, multiple channels of video programming other than an open video system as defined by Sec. 76.1500(a). Such systems include, but are not limited to, cable television systems, BRS/EBS systems, direct broadcast satellite systems, other systems for providing direct-to-home multichannel video programming via satellite, and satellite master antenna systems. (i) Navigable Service. A multichannel video programmer's video programming and Emergency Alert System messages (see 47 CFR part 11). (j) Navigation Devices. Devices such as converter boxes, interactive communications equipment, and other equipment used by consumers to access multichannel video programming and other services offered over multichannel video programming systems. (k) Open Standards Body. A standards body (1) whose membership is open to consumer electronics, multichannel video programming distributors, content companies, application developers, and consumer interest organizations, (2) that has a fair balance of interested members, (3) that has a published set of procedures to assure due process, (4) that has a published appeals process, and (5) that strives to set consensus standards. (l) Service Discovery Data. Information about available Navigable Services and any instructions necessary to request a Navigable Service. (m) Trust Authority. An entity that issues certificates and keys used by a [[Page 14052]] Navigation Device to access Navigable Services that are secured by a given Compliant Security System. 0 3. Revise Sec. 76.1206 to read as follows: Sec. 76.1206. Equipment sale or lease charge subsidy prohibition. After January 1, 2017, multichannel video programming distributors shall state the price for Navigation Devices separately on consumer bills. 0 4. Add Sec. 76.1211 to read as follows: Sec. 76.1211. Information Necessary to Assure a Commercial Market for Navigation Devices. (a) Each multichannel video programming distributor shall make available to each Navigation Device that has a Certificate the Service Discovery Data, Entitlement Data, and Content Delivery Data for all Navigable Services in published, transparent formats that conform to specifications set by Open Standards Bodies in a manner that does not restrict competitive user interfaces and features. (b) If a multichannel video programming distributor makes available an application that allows access to multichannel video programming without the technological need for additional multichannel video programming distributor-specific equipment, then it shall make Service Discovery Data, Entitlement Data, and Content Delivery Data available to competitive Navigation Devices without the need for multichannel video programming distributor-specific equipment. (c) Each multichannel video programming distributor shall support at least one Compliant Security System. (1) At least one supported Compliant Security System shall enable access to all resolutions and formats of the multichannel video programming distributor's Navigable Services with the same Entitlement Data to use those Navigable Services as the multichannel video programming distributor affords Navigation Devices that it leases, sells, or otherwise provides to its subscribers. (2) Entitlement Data shall not discriminate on the basis of the affiliation of the Navigation Device. (d) On any device on which a multichannel video programming distributor makes available an application to access multichannel video programming, the multichannel video programming distributor must support at least one Compliant Security System that offers access to the same Navigable Services with the same rights to use those Navigable Services as the multichannel video programming distributor affords to its own application. [FR Doc. 2016-05763 Filed 3-15-16; 8:45 am] BILLING CODE 6712-01-P
| Category | Regulatory Information | |
| Collection | Federal Register | |
| sudoc Class | AE 2.7: GS 4.107: AE 2.106: | |
| Publisher | Office of the Federal Register, National Archives and Records Administration | |
| Section | Proposed Rules | |
| Action | Proposed rule. | |
| Dates | Submit comments on or before April 15, 2016. Submit reply comments on or before May 16, 2016. Written comments on the Paperwork Reduction Act proposed information collection requirements must be submitted by the public, Office of Management and Budget (OMB), and other interested parties on or before May 16, 2016. | |
| Contact | For additional information on this proceeding, contact Brendan Murray, [email protected], of the Media Bureau, Policy Division, (202) 418-1573. Contact Cathy Williams, [email protected], (202) 418-2918 concerning PRA matters. | |
| FR Citation | 81 FR 14033 |