[Federal Register Volume 81, Number 51 (Wednesday, March 16, 2016)]
[Proposed Rules]
[Pages 14033-14052]
From the Federal Register Online via the Government Publishing Office [www.gpo.gov]
[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 PRA@fcc.gov and to 
Nicholas A. Fraser, Office of Management and Budget, via email to 
Nicholas_A._Fraser@omb.eop.gov or via fax at 202-395-5167.

FOR FURTHER INFORMATION CONTACT: For additional information on this 
proceeding, contact Brendan Murray, Brendan.Murray@fcc.gov, of the 
Media Bureau, Policy Division, (202) 418-1573. Contact Cathy Williams, 
Cathy.Williams@fcc.gov, (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 fcc504@fcc.gov 
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