Category Archives: Intellectual Property

Copyright and Web-DVR Broadcasting: The Latest Aereo and FilmOn X Decisions

Two recent decisions have added more discord among federal courts as to the question of whether technology that allows users to record copies of over-the-air broadcasts on remote servers for later web viewing violates broadcasters’ exclusive public performance rights under the Copyright Act.  On October 8, 2013 the US District Court for the District of Massachusetts aligned itself with the Second Circuit, holding that such services do not violate broadcasters’ performance rights in Hearst Stations v. Aereo (Aereo).  Reaching the exact opposite conclusion back on September 5, 2013, was the US District Court for the District of Columbia in Fox Television v. FilmOn X (FilmOn X).

The split among District Courts on this issue will likely lead to further appeals and decisions by the respective Court of Appeals.  Ultimately, the issue could be heard by the Supreme Court in the coming years, depending on whether the Courts of Appeals continue to be similarly split.

Before going to the current state of the law, this post will describe the technology that is at the heart of these copyright disputes by using Aereo as the example platform.

What is Aereo?

According to Aereo’s website, “Aereo is a technology platform that you can use to watch live broadcast television at home or on the go.” A potential Aereo user purchases a subscription from Aereo, which, in exchange, provides the user with a remote, cloud-based DVR to set and watch recordings.  The benefit to users is that the service only requires a compatible internet-enabled device, without the need to purchase antennas, boxes, or cables.  The concept is extremely simple:


Once a potential user becomes an Aereo member, the user logs in and is assigned a miniaturized, private, remote antenna and DVR.  Aereo offers technology to give consumers access to their antenna and DVR via a web browser and supported internet-enabled devices.  Once the user has connected to his remote Aereo antenna, the user can then access the Aereo platform to view all major broadcast networks live in HD.  Alternatively, the user can enable their remote DVR to set recordings and watch the broadcasts later whenever the user wants.

How does Aereo Work?

When Aereo decides to enter a particular geographic region or market, it installs an array of mini antennas.  Each of these mini antennas are no larger than the size of a dime.  A large number of mini antennas are aggregated on a circuit board, which also contains other electronic components essential to Aereo’s Internet broadcast system.Antenna

While the antenna may be assigned to an individual user, they are generally available for dynamic allocation by the tuner server.  Essentially, this means that a specific antenna is assigned to one specific individual user only when that user is watching television via Aereo, but is then assigned to a different user when the first user is done.  Nevertheless, no single antenna is used by more than one user at a single time, and all dynamic antennas are shared. The antennas are networked to a tuner router and server, which in turn link to a video encoder. The encoder converts the signals from the antennas into a digital video format for viewing on computers and mobile devices.

When a user selects a channel to watch through Aereo’s web or mobile app, the user’s request is sent to Aereo’s web server. The server sends a command to the tuner router, which then identifies an available antenna and encoder slot.  Once the antenna begins receiving the signal, data for the requested channel flows from the antenna to the antenna router and then to the video encoder, where it is stored on an Aereo remote hard drive in a unique directory created for the specific user.  The data then goes through the distribution endpoint, over the Internet to the web or mobile app for the user’s consumption.

The Dispute

In the recent Aereo case, Hearst claimed that Aereo’s services violate its exclusive rights under Section 106 of the Copyright Act to: (1) publicly perform, (2) reproduce, (3) distribute, and (4) prepare derivative works based on its copyrighted programming.  The Court’s analysis focused on the first claim relating to public performance, which will be discussed below.

The Court quickly rejected Hearst’s claim that Aereo infringed its exclusive right to reproduce its works, stating that “holding a media company directly liable just because it provides technology that enables users to make copies of programming would be the rough equivalent of holding the owner of a copy machine liable because people use the machine to illegally reproduce copyrighted materials.”  Similarly, with respect to its distribution right, the Court sided with Aereo, relying heavily on the fact that Aereo’s technology does not allow users to download (only stream) the copyrighted content.  Likewise, with respect to Hearst’s exclusive right to make derivative works, the Court quickly disposed of Hearst’s argument that by reformatting intercepted programming Aereo violated the broadcaster’s right to prepare derivative works.  As the Court reasoned, “Hearst has presented no legal authority nor is the Court aware of any for the proposition that Aereo’s technology creates a derivative work merely by converting programs from their original digital format to a different digital format compatible with internet streaming.”

Public Performance Right

Quickly dismissing the above claims, the Court focused its discussion on Hearst’s first claim regarding its exclusive right to publicly perform its copyrighted works.  The Copyright Act gives copyright owners of audiovisual works the exclusive right, among others, to “perform the copyrighted work publicly.”  Section 101 of the Act provides that “to perform” an audiovisual work means “to show its images in any sequence or make the sounds accompanying it audible.”  To make matters more confusing, the statute distinguishes between public and private performances.  Having become known as the “Transmit Clause”, Section 101 provides that “to perform a work publicly” means to transmit a performance of the work to the public, “by means of any device or process, whether the members of the public capable of receiving the performance […] receive it in the same place or in separate places and at the same time or at different times.”  For additional insight – or perhaps more confusion – the House Committee on the Judiciary’s Report to the Copyright Act (revised 1976) provides a discussion on the intended meaning of “perform” and “public performance”:

“Concepts of public performance and public display cover not only the initial rendition or showing, but also any further act by which that rendition or showing is transmitted or communicated to the public. Thus, for example: a singer is performing when he or she sings a song; a broadcasting network is performing when it transmits his or her performance (whether simultaneously or from records); a local broadcaster is performing when it transmits the network broadcast; a cable television system is performing when it retransmits the broadcast to its subscribers; and any individual is performing whenever he or she … communicates the performance by turning on a receiving set.”

The Decision

The District Court for the District of Massachusetts in Aereo relied on the Second Circuit’s holding that similar DVR technology does not infringe a copyright holder’s exclusive right to perform its work publicly.  In the 2008, the Second Circuit decided the Cablevision case, which held RS–DVR technology non-infringing of the original broadcaster’s public performance right because the technology’s manner of transmitting a recorded program to the viewer who recorded it did not constitute a public performance.  The Cablevision opinion concluded:

“In sum, we find that the transmit clause directs us to identify the potential audience of a given transmission, i.e., the persons “capable of receiving” it, to determine whether that transmission is made “to the public.” Because each RS–DVR playback transmission is made to a single subscriber using a single unique copy produced by that subscriber, we conclude that such transmissions are not performances “to the public,” and therefore do not infringe any exclusive right of public performance.”

Likewise, earlier this year, the Second Circuit applied its reasoning from Cablevision in WNET, Thirteen v. Aereo (WNET) to the very Aereo service that was before the District of Massachusetts Court.  In WNET, the Second Circuit affirmed their Cablevision decision and found that Aereo’s transmissions to subscribers also did not infringe.  The court described Cablevision’s holding as resting on two essential facts:

1)      The RS–DVR system created unique copies of each program a customer wished to record; and

2)      A customer could only view the unique copy that was generated on his behalf.

Adopting the Second Circuit’s rationale, the Massachusetts court found that Aereo’s system is consistent with the two key factors above because it (1) employs individually-assigned antennas to create copies unique to each user and (2) only at the user’s request.

The Split: FilmOn X

Not persuaded by the Second Circuit’s Cablevision or WNET decisions, the District Court for the District of Columbia came out the other way in the FilmOn X case.  Quite simply, its decision rested on a different, and not unreasonable, statutory interpretation of the Transmit Clause.  The FilmOn X court reasoned that what makes a transmission public is not the intended audience of any given copy of the program, but the intended audience of the initial broadcast.

At the end of the day, this battle of statutory interpretations may need to be settled by the Supreme Court, or – don’t hold your breath – an Act of Congress.

Software Patents: The Federal Circuit Goes on a WildTangent

In the next few weeks, the U.S. Supreme Court will decide whether to grant certiorari in the patent dispute between WildTangent and Ultramercial.  The case, if heard by the Court, would be a suitable vehicle to provide guidance on how 35 U.S.C. § 101 applies to computer implemented inventions.  In essence, the question presented would read something like:  At what point does a method patent on an otherwise abstract concept sufficiently claim reference to a computer (or computer-implemented service like the Internet) to make such an abstract concept patent eligible under 35 U.S.C. § 101?  To put this question in context, here’s a little background on the parties involved and the lower courts’ decisions.

The Infringer: WildTangent

WildTangent operates a games service that allows consumers around the world to access downloadable, online, and social games via the Internet. WildTangent’s service reaches over 20 million monthly gamers in the United States and Europe with a catalog of more than 1,000 games from nearly 100 developers.  Rather than paying to play, consumers can let an advertiser sponsor free game play sessions. To do so, the consumer must agree to display an advertisement before he is given access to the game.

The Patent Holder: Ultramercial, LLC

According to Ultramercial’s website, Ultramercial is a technology company that offers patented financial engines for monetizing online content along with integrated end-to-end solutions.  They developed an ad model consisting of “interactive, full-page ads that are always served in exchange for premium content or services.”  Ultramercial, more importantly for this post, is the patent holder of U.S. Patent No. 7,346,545 (the ‘545 patent).  The ‘545 patent claims a method for distributing copyrighted products (e.g., songs, movies, books) over the Internet where the consumer receives a copyrighted product for free in exchange for viewing an advertisement, and the advertiser pays for the copyrighted content.  You know, kind of like this:

The Dispute

In 2011, WildTangent challenged a ruling that it had infringed the ‘545 patent owned by Ultramercial, LLC.  Specifically, the ′545 patent claims a particular internet and computer-based method for monetizing copyrighted products, consisting of the following steps:

(1) receiving media products from a copyright holder, (2) selecting an advertisement to be associated with each media product, (3) providing said media products for sale on an Internet website, (4) restricting general public access to the media products, (5) offering free access to said media products on the condition that the consumer view the advertising, (6) receiving a request from a consumer to view the advertising, (7) facilitating the display of advertising and any required interaction with the advertising, (8) allowing the consumer access to the associated media product after such display and interaction, if any, (9) recording this transaction in an activity log, and (10) receiving payment from the advertiser.

At issue was whether Ultramercial’s process-type patent (also referred to as method patents) claims an abstract idea.  If so, the patent should be held invalid as abstract ideas have long been held to be non-patentable subject matter.  WildTangent argued that the idea of using advertising as a form of currency is abstract and vague, like the abstract concept of hedging, which proved patent-ineligible in the Supreme Court’s Bilski decision.  Not persuaded, Judge Rader, writing for the Court of Appeals for the Federal Circuit, upheld Ultramercial’s patent, stating that it “does not simply claim the age-old idea that advertising can serve as currency. Instead [it] discloses a practical application of this idea.”

Then, once again, after being ordered by the Supreme Court to reexamine the case in light of the Court’s Mayo decision, the Federal Circuit upheld its decision this past June and ruled that Ultramercial’s patents were not ineligible subject matter.

The Law of Patent Eligibility under Section 101

Section 101 of the Patent Act establishes the subject-matter eligibility requirement for all patents. It provides that “whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.” Section 101’s subject-matter eligibility is considered a threshold check, since the actual patentability of a claimed invention ultimately depends on more rigorous conditions, such as novelty, non-obviousness, and adequate disclosure.

Nevertheless, case law has established three categories of subject matter that fall outside the eligibility bounds of § 101: (1) laws of nature, (2) natural phenomena, and (3) abstract ideas.  As the Supreme Court explained in its Bilski decision, these non-patentable categories are considered the “the basic tools of scientific and technological work” and accordingly they are “part of the storehouse of knowledge of all men” and women.  Judge Rader, writing for the Federal Circuit, explained “an abstract idea is one that has no reference to material objects or specific examples—i.e., it is not concrete.”

A claim can embrace an abstract idea and be patentable when drawn to an application of that idea.  On the other hand, a claim is not patent eligible if the claim is to the abstract idea itself.  The inquiry here is to determine on which side of the line the claim falls: does the claim cover only an abstract idea, or instead does the claim cover an application of an abstract idea?  In determining on which side of the line the claim falls, the relevant inquiry is whether a claim, as a whole, includes meaningful limitations restricting it to an application, rather than merely an abstract idea.

Okay, but what exactly does “meaningful limitation” mean?  Well, it’s helpful, for starters, to describe what “meaningful limitation” does not mean.

First, if a claim covers all practical applications of an abstract idea, it is not meaningfully limited.  This much is not hotly disputed.  That is, it is well settled law that if a claim preempts all practical uses of an idea, then it is not patent eligible.  For example, one cannot claim the formula for converting binary-coded decimal numerals to pure binary numerals because this mathematical formula has no substantial practical application except in connection with digital computing.

Second, going a step further, it is also well established that even if a claim does not entirely preempt all application of an abstract idea, courts will still not find meaningful limitation to the extent the claim contains only insignificant constraints on the use or implementation of the invention.  For example, simply tying the claim to a relevant audience, a category of use, field of use, or technological environment will not carry the day; the claim will still be deemed patent-ineligible.

So now that it is clear what “meaningful limitation” is not, here’s where courts come out on the much less settled law of what “meaningful limitation” is.  A claim is said to be meaningfully limited if it requires a particular machine implementing a process or a particular transformation of matter.  A claim also will be limited meaningfully when, in addition to the abstract idea, the claim recites added limitations which are essential to the invention. In those instances, the added limitations do more than recite pre- or post-solution activity, they are central to the solution itself. And, in such circumstances, the abstract idea is not wholly pre-empted; it is only preempted when practiced in conjunction with the other necessary elements of the claimed invention.

The Federal Circuit’s Questionable Rationale

When assessing computer implemented claims, the Federal Circuit admits that the mere reference to a computer will not save a method claim from being deemed too abstract to be patent eligible.  However, in the same opinion, the Federal Circuit stated that the fact that a claim is tied to a computer is, nevertheless, an important indication of patent eligibility.  In Judge Rader’s opinion, “this tie to a machine moves it farther away from a claim to the abstract idea itself […] [and] makes it less likely that the claims will pre-empt all practical applications of the idea.”  The Federal Circuit goes even further and finds “meaningful limitation” when a claim references a computer in such a way that the computer plays a meaningful role in the performance of the claimed invention.  The difficulty in the standard created by the Federal Circuit is that “meaningful limitation” in the context of a computer-based method patent is now defined as one in which the computer plays a “meaningful role”.  This, to legal practitioners and research-and-developers alike, is a difficult concept to implement and strategize around.  One might even go as far as to say that the “meaningful limitation” standard is itself an abstract idea under the Ultramercial decision.

Ultimately, the Federal Circuit’s decision seems to rely heavily on procedural considerations.  As the Federal Circuit stated, “the district court erred in requiring the patentee to come forward with a construction that would show the claims were eligible. The district court held the asserted claim to be ineligible because it is “abstract.” In this procedural posture, the complaint and the patent must by themselves show clear and convincing evidence that the claim is not directed to an application of an abstract idea, but to a disembodied abstract idea itself.”

It would seem that the Supreme Court could – and should – provide useful guidance on this notion.  Otherwise, seemingly, any claimed invention that simply invokes computers or applications of computer technology would survive summary judgment and be put to a trier of facts, which of course would likely have significant impacts on the costs and burdens associated with patent litigation.

Blurred Lines: Using Google AdWords after 1-800-Contacts

Last month, the 10th Circuit issued its opinion in 1-800 Contacts v.  This decision essentially establishes that using a competitor’s trademark in Keyword advertising will not constitute infringement, to the extent the competitor’s mark is not used within the sponsored link.

The 1-800-Contacts case arises out of advertising through AdWords, which is a program offered by Google. A company using AdWords pays Google to feature one of its ads within sponsored search results whenever a designated term (a “Keyword”) is used in a Google search.  The issue before the Court was whether the Lanham Act was violated by an advertiser’s use of Keywords that resembled a competitor’s service mark.  The Lanham Act prohibits the infringement of trademarks used to identify products, and of service marks used to identify services.  1-800-Contacts is a supplier of replacement contact lenses. It owns the federally registered service mark “1800CONTACTS”. One of its competitors is  1-800-Contacts sued asserting that infringed the 1800CONTACTS mark by purchasing Keywords resembling the mark. 1-800-Contacts alleged that’s conduct directed potential customers to under the theory of “initial-interest confusion”.

Screenshot of search results from Googling "Velcro"...trademark law humor.
Screenshot of search results from Googling “Velcro”…trademark law humor.

Before getting too far into the Court’s legal analysis, it is helpful to understand a little more about Google search and how the AdWords program fits into the marketing strategies of companies.  As most everyone is aware, a typical Google search serves up two types of results: (1) organic results, and (2) sponsored links. Organic results are links generated by Google’s search algorithms and are sorted by relevance and quality.  Google does not serve up advertisements among the organic results. However, through the AdWords program a company can pay Google to be displayed as a sponsored link.  As you can see from the screenshot above, sponsored links (the first 3 results) include advertising copy and links to the advertisers’ websites.

For its ad to appear as a sponsored link, an advertiser bids to reserve a particular word or phrase (i.e., the Keywords) that triggers the display of its ad.  The serving up of the ad based on a user’s search is referred to as an “Impression”. An advertiser pays Google only if the user actually clicks on its Impression.  The per-click amount that the advertiser owes Google is based on the advertiser’s bid price for the Keyword underlying the Impression.  Advertisers who bid higher amounts will generally receive greater visibility to consumers based on their higher placement among the sponsored link results.  Essentially, a Google search for “1800CONTACTS” resulting in a sponsored link for could occur only if had bid on that exact term or on some phrase containing that exact term.

Putting aside search engine optimization and marketing and returning now to the law, the Lanham Act protects service marks, in addition to trademarks.  A service mark is “any word, name, symbol, or device, or any combination thereof” that is used “to identify and distinguish the services of one person, including a unique service, from the services of others and to indicate the source of the services, even if that source is unknown.”  The service mark “1800CONTACTS” is such a mark.  To succeed on an infringement claim under the Lanham Act, a plaintiff must show:

  1. it has a protectable interest in the mark;
  2. the defendant has used an identical or similar mark in commerce; and,
  3. the defendant’s use is likely to confuse consumers.

With elements (1) and (2) easily satisfied, the only issue remaining for the Court was whether’s use resulted in (3) the likelihood of confusion.  1-800-Contacts’ theory of confusion is based on initial-interest confusion. 1-800-Contacts argues that although never published any ads containing a 1-800-Contacts mark in their text, bid on Keywords causing its ads to appear in response to searches for the 1800CONTACTS mark.  This, argues 1-800-Contacts, diverts customer interest away from 1-800-Contacts’ website and toward’s website.  The classic example of initial-interest confusion exists when a consumer seeks a particular company’s product, but is lured to the product of a competitor by that competitor’s use of the other company’s same or a similar mark.  Improper confusion occurs even if the consumer becomes aware of the competitor’s actual identity before purchasing the product.  The Court relied on a six-factor analysis, known as the King of the Mountain factors, to decide whether a likelihood of confusion exists:

  1. the degree of similarity between the marks;
  2. the intent of the alleged infringer in adopting its mark;
  3. evidence of actual confusion;
  4. the relation in use and the manner of marketing between the goods or services marketed by the competing parties;
  5. the degree of care likely to be exercised by purchasers; and
  6. the strength or weakness of the marks.

The Court emphasized that initial-interest confusion occurs when a consumer in search of the plaintiff’s product is lured to the product of the defendant, as in a bait-and-switch tactic, notwithstanding that the confusion is dispelled by the time of sale.  The Court, on behalf of 1-800-Contacts, summarized the initial-interest confusion argument as follows:

A consumer enters a query for “1–800 Contacts” on Google; sees a screen with an ad for that is generated because of’s purchase of one of the nine Challenged Keywords; becomes confused about whether is the same source as, or is affiliated with, 1–800; and therefore clicks on the ad to view the site. has exploited its use of 1–800’s mark to lure the confused consumer to its website.

While making a convincing, yet somewhat facetious argument, the Court ultimately found the actual data associated with’s AdWords campaign to be more compelling.  Citing the actual AdWords data, the Court detailed just how often consumers were lured by the Impression. Specifically,’s use of the 1800CONTACTS-like Keywords yielded 1,626 Impressions over an eight month period.  Of these 1,626 instances, only 25 resulted in a user actually clicking on the ad for  As the Court stated,

The users in those 25 instances may have been confused into thinking that was affiliated with 1–800, or they may simply have wished to look at the offerings of those whom they knew to be 1–800’s competitors. What we can say, though, is that initial-interest confusion occurred at most 1.5% of the time that a ad was generated by a Challenged Keyword in those eight months. This number cannot support an inference that’s keyword activity was likely to “lure” consumers away from 1–800.  It is thus insufficient to justify relief.  We conclude that the factors other than evidence of actual confusion (even if we assume that 1–800’s mark is a strong one) firmly support the unlikelihood of confusion. This case is readily distinguishable from Australian Gold, in which the alleged infringer used its competitor’s trademarks on its websites.

Note: The Court refers to the Australian Gold case, in which the defendants used Australian Gold’s trademarks on their own websites and placed Australian Gold’s marks in hidden codes associated with their websites (i.e., metatags).  These acts were found to create initial-interest confusion because they caused Internet searches for Australian Gold trademarks to return search results that contained the defendant’s links within a search engine’s organic listings.

The takeaway here is that while using the marks of a competitor to lure consumers into potentially purchasing competing products sounds a lot like a cause of action under the Lanham Act, the context and results of the underlying marketing campaign might show that such use did not actually cause confusion.  Where context and data do not support a finding of actual confusion (and by apparent extension, a likelihood of confusion), then, at least in the 10th Circuit, the trademark owner will have an uphill battle under the theory of initial-interest confusion.

DiOS Mio! Apple’s License for Internal Apps (Part 3 of 3)

In this third and final post on developing internal apps pursuant to Apple’s iOS Developer Program Enterprise License Agreement (the “License”), I will address the terms governing app deployment and distribution.  Also, worth mentioning, are the unique requirements related to Apple’s Pre-release Software that may be made available under the Program.

Creative Commons Attribution: Brion VIBBER
Creative Commons Attribution: Brion VIBBER

As a quick recap, Part 1 discussed the rights and restrictions as they relate to the use of Apple Software; while Part 2 focused on the rights and restrictions as they relate to the use of Internal Apps (i.e., the software programs developed for specific use with an iPhone or iPad for internal deployment to, and use by, the company’s employees).  Leaving now the Internal App development aspects of the license, this post will fast forward and direct its focus on distributing those Internal Apps across the Licensee’s enterprise.

Deployment of Internal Apps

Internal Apps developed under the License may be deployed on Deployment Devices (i.e., the test devices used during the development process and other iOS products owned or controlled by the company) in two ways: (1) General Deployment – deployment for internal use by the company’s employees, and (2) Limited Customer Deployment – deployment for use by customers either on the company’s physical premises or under the direct supervision and physical control of the company’s employees in other locations.  Each of these methods of deployment will be discussed in turn below.

General Deployment

Prior to deployment, all Internal Apps must be signed with an Apple-issued certificate in order to be installed on Deployment Devices.  The company is solely responsible for determining which employees should have access to the Internal Apps and Deployment Devices.  Additionally, it is the company’s responsibility to manage and monitor employees’ use of the Internal Apps and Deployment Devices on an ongoing basis.  The company must promptly retrieve Deployment Devices from individuals who are no longer employed or engaged by the company.  Similarly, the company must cut off such individuals’ access to the Apple Software, Apple-issued digital certificates, and Provisioning Profiles.

Limited Customer Deployment

In addition to the General Deployment to the company’s employees, the License allows customers of the company to use its Internal Apps, but only (i) on the company’s physical premises, or (ii) in other locations, provided all such use is under the direct supervision and physical control of an employee of the company (e.g., a sales presentation to a customer).  This Limited Customer Deployment is subject to Apple’s right to review and approve or reject any Internal App that the company would like to deploy for use by its customers.

Pre-Release Apple Software

Throughout participation in the Program, Apple may make certain Pre-release Software available to the Licensee.  Use of this Pre-release Software is for evaluation and development purposes only.  The Pre-release Software should not be used by the company in a commercial operating environment or with important data.  To the extent the company chooses to use Pre-release Software, any research or development that it performs with respect to the pre-release versions of the Apple Software is done entirely at the company’s risk.

If an Authorized Test Device contains any Pre-release Software, it is the company’s responsibility to restrict access to these Authorized Test Devices to Authorized Developers.  Furthermore, the company’s Authorized Developers must not disclose or otherwise transfer Authorized Test Devices containing Pre-release Software to any third party.  By installing any Pre-release Software on the company’s Authorized Test Devices, Apple reserves the right to lock these devices in testing mode.  This could render Authorized Test Devices incapable of being restored to their original condition.

Confidential Nature of Pre-Release Apple Software

The Pre-release Software is Apple’s Confidential Information and is subject to the confidentiality obligations under the License.  The confidentiality obligations remain in effect until the Pre-release Software (or features thereof) is commercially released.  Pursuant to the License, the company must protect Apple’s Confidential Information using at least the same degree of care that it uses to protect its own confidential information of similar importance.  The Licensee is allowed to use Apple’s Confidential Information only for the purpose of evaluating and developing Internal Apps.  The company is prohibited from disseminating Apple’s Confidential Information to anyone other than: (i) the company’s employees and contractors who have a need to know; and (ii) who are bound by a written agreement that prohibits unauthorized use or disclosure of the Apple’s Confidential Information.

DiOS Mio! Apple’s License for Internal Apps (Part 2 of 3)

In this second part of the three-part post discussing the Apple iOS Developer Enterprise Program (the “Program”), I will continue by describing the terms of Apple’s iOS Developer Program Enterprise License Agreement (the “License”) that specifically govern the apps developed from the Apple Software.  Where Part 1 was limited to the rights and restrictions as they relate to the use of Apple Software, this Part 2 focuses on the rights and restrictions as they relate to the use of Internal Apps.  These “Internal Apps” are software programs developed for specific use with an iOS Product (e.g., iPhone or iPad) for internal deployment to, and use by, the company’s (i.e., the “Licensee’s”) employees.

Attribution: Zacfranks
Attribution: Zacfranks
Note: Yes, I am aware that this is an Android App :)

As I mentioned in Part 1, the Licensee retains all ownership and interest in the Internal Apps it develops using the Apple Software.  Nevertheless, the Licensee should be well advised that Apple will not treat them as confidential.  Apple expressly disclaims any confidentiality obligations or use restrictions with respect to information that a Licensee provides in connection with the Program, including the Internal Apps.  This means that Apple may use and freely disclose any such information on an unrestricted basis without notifying the Licensee.

APIs and Functionality

The following are requirements that a Licensee’s Internal Apps must adhere to with respect to Application Programming Interfaces (APIs) and functionality.

  • Internal Apps may use documented APIs only in the manner prescribed by Apple
  • Internal Apps must not use or call any private APIs
  • Internal Apps must not download or install executable code
  • Internal Apps must not facilitate commerce, credits, or purchases of any kind
  • Internal Apps may only read data from, or write data to, the Internal App’s designated container area on the device
  • Internal Apps must have at least the same features and functionality when run by a user in compatibility mode on an iPad, except where any feature or functionality is not supported by a particular hardware device
  • Internal Apps must comply with Apple’s Human Interface Guidelines

Data & Privacy

Under the License, a company’s Internal Apps may not collect user or device data without prior end-user (i.e., employees’) consent.  This consent requirement means the Licensee must provide clear notice to users regarding the company’s collection, use, and disclosure of user or device data.  Further, even where consent is obtained, the data collected can only be used to provide a service or function that is directly relevant to the use of the Internal App.  Under no circumstances, can a Licensee use analytics software in their Internal Apps to collect and send device data to a third party.  Additionally, the Licensee must take appropriate steps to protect such data from unauthorized use, disclosure, or access by third parties.  If a user ceases to consent or affirmatively revokes consent for the Internal App’s collection, use, or disclosure of his or her user or device data, the Licensee must promptly cease all such use.  In other words, the company must provide its employees with an opt-out mechanism.

Internal Apps that offer location-based services or functionality must notify and obtain consent from an end-user before his or her location data is collected, transmitted, or otherwise used by the Internal App.  If such Internal App uses location-based APIs to provide real-time navigation, the Licensee must have an end-user license agreement (e.g., a Terms of Service) that includes the following notice: YOUR USE OF THIS REAL TIME ROUTE GUIDANCE APPLICATION IS AT YOUR SOLE RISK. LOCATION DATA MAY NOT BE ACCURATE.

If the Licensee develops Internal Apps that collect or record images, pictures, or voice content (collectively “Recordings”), then the company must comply with all applicable privacy laws and regulations.  Depending on the type of Recording and the intended use of such Recording, this may require notice be provided and/or consent be obtained from employees; as, for example, consent to use the employees’ likeness or image, to the extent the Internal App contains photo-capture functionality.  In addition, per the License, a company’s Internal Apps must display an obvious audio, visual, or other indicator to the end-user as part of any Internal App that is making an active Recording.

Specific Types of Content

All content used within the Licensee’s Internal Apps must either be owned by the company, or properly licensed by the company from the content owner.  If the company’s Internal Apps allow employees to send SMS messages, then the company must inform its employees, prior to their use of such functionality, that standard text messaging rates or other carrier charges may apply.  Internal Apps may include sweepstake or contest functionality; however, the Licensee must be named as the sole sponsor of the promotion.


The Licensee is responsible for preventing any unauthorized person from having access to Provisioning Profiles, digital certificates, and corresponding private keys.  Additionally, the Licensee must immediately notify Apple in writing if it has any reason to believe there has been a compromise of any Provisioning Profiles, digital certificates, or corresponding private keys.  The Licensee cannot provide or transfer Apple-issued digital certificates or Provisioning Profiles provided under the Program to any third party, except for a third party who is developing an Internal App on the company’s behalf.

Additional Functionality

The following sections describe terms that are specific to certain services available with the Apple Software that may be used to develop additional functionality in connection with a Licensee’s Internal Apps.

  • APN (Apple Push Notification service) or Local Notifications

If the Licensee’s Internal Apps send Push Notifications via the APN or Local Notifications, the Licensee must first obtain end-user consent prior to receiving such notifications.  The company cannot disable or interfere with any Apple implemented consent panels or any Apple system preferences for enabling or disabling Notifications functionality.  If an employee’s consent to receive Push Notifications is denied or later withdrawn, the company may not send that employee any further Push Notifications.  As a condition to using the APN or delivering Local Notifications, the company may not transmit sensitive personal or confidential information belonging to an individual (e.g., a social security number, financial account or transactional information, or any information where the individual may have a reasonable expectation of secure transmission) as part of any such notification.  Any Push Notifications that the Licensee sends via the APN, may be transmitted across various public networks, in various forms of media.

  • Mobile Device Management (MDM) Service

Like the Internal Apps themselves, the Licensee’s use of the MDM Service is solely for its internal, in-house management of employees’ Deployment Devices.  Before a company can use the MDM Service, it must install an MDM Profile on each iOS Product that will be managed under the MDM Service.  Use of the MDM Service requires the Licensee to maintain a secure server to interact with Apple’s APN server.  As part of the MDM Service, Apple will provide the Licensee with the “MDM Protocol”, which must be treated as Apple’s Confidential Information.

Prior to installation of the MDM Profiles, the Licensee must provide notice to its employees that it will be able to interact with their Deployment Devices remotely.  Such interaction includes: inspecting, installing, or removing profiles; viewing which Internal Apps are installed; using secure erase functions; and, enforcing device passcodes.  All information that the Licensee obtains through the use of the MDM Service may only be used for the company’s internal information technology and device management purposes; such as, locking the device for security purposes, or remotely wiping a lost device.

  • iCloud Storage

The Licensee’s use of the iCloud Storage APIs and the iCloud service is governed by additional terms governing the iCloud service for software development and testing in connection with the Licensee’s Internal Apps.  Most importantly, the Licensee’s Internal Apps are only permitted to use the iCloud service and the iCloud Storage APIs for the purpose of (1) storage and retrieval of key value data (e.g., a list of stocks in a finance App) for Internal Apps, and (2) allowing its employees to access user-generated documents and files through the iCloud service.

  • Passbook

The Licensee’s development of Passes, and use of Pass IDs, must be in accordance with the terms of the License and the Additional Terms for Passes.  “Pass(es)” are one or more digital passes (e.g., movie tickets, coupons, loyalty reward vouchers, boarding passes, membership cards, etc.) developed by the company, under the company’s trademark or brand, and which are signed with the company’s Pass ID.  A “Pass ID” means the combination of an Apple-issued certificate and Push Application ID that is used to sign the company’s Passes and/or communicate with the APN.

The Licensee may only use the Pass ID for purposes of digitally signing Passes and/or for purposes of using the APN service with Passes.  The Licensee is limited to distributing Passes only to its employees for internal purposes.  Passes may only operate and be displayed in Passbook, which is Apple’s designated container area for the Pass, or through Passbook on the lock screen of an iOS Product.  Within the Passes, the Licensee must state its name and address, and the contact information to which any employee questions, complaints, or claims with respect to its Passes should be directed.  Apple reserves the right to review and approve or reject any Pass that the company intends to distribute for use by its employees.

  • Twitter

If the Licensee’s Internal Apps access the Twitter service through the Twitter API, such access is subject to Twitter’s terms of service (

  • Address Book

If the Licensee’s Internal Apps access data from an employee’s Address Book through the Address Book API, then the Licensee must notify and obtain consent from the user before his or her Address Book data is accessed or used by the Internal App.

To be Continued…

In the third and final part of this three-part post, I will address the terms governing app deployment, as well as the unique requirements related to Apple’s Pre-release Software that may be made available under the Program.  Stay tuned!

DiOS Mio! Apple’s License for Internal Apps (Part 1 of 3)

The purpose of this three-part post is to provide an overview of the Apple iOS Developer Enterprise Program (the “Program”) from a legal perspective.  These posts should provide guidance to business-unit directors and their software developers as they prepare to distribute in-house, mobile applications on Apple-branded products running the iOS to their employees.  In this Part, I will highlight the general legal obligations and restrictions related to Apple’s iOS Developer Program Enterprise License Agreement (the “License”).  This part will focus only on the License as it relates to the use of the Apple Software.  In future posts, I will discuss how the License governs the subsequently developed apps and their deployment.

Ed g2s
Ed g2s

Overview: Apple’s iOS Developer Enterprise Program

The Program provides companies with tools to develop, test, and distribute proprietary, in-house iOS apps to employees and, under very limited circumstances, customers.  These “Internal Apps” are software programs developed for specific use with an iOS Product (e.g., iPhone or iPad) for internal deployment to, and use by, the company’s employees.  As a general rule, the Program is not intended for the creation of other apps that may be used, distributed, or otherwise made available to other companies, distributors, resellers, or members of the general public.

General Program Terms: The Apple Software

Before a company can begin developing Internal Apps using the Apple Software, it will have to accept the terms of the License. As defined by the license, “Apple Software” includes the Apple iOS, Provisioning Profiles, and the all-important Software Development Kit (“SDK”, i.e., the documentation, software, applications, sample code, simulator, tools, libraries, APIs, etc.).  The company (the “Licensee”) must be sure that the person accepting the License terms has the right and authority to enter into the License on behalf of his/her company.  For companies with multiple subsidiaries and affiliates, it is important to note that the License is both non-sublicensable and non-transferable.  Once the License is entered into, Apple grants the Licensee the right to (1) use Apple Software for developing and testing Internal Apps; and, (2) deploy their Internal Apps for the Licensee’s internal purposes.

While Apple grants a rather broad License for a nominal fee of $299, they at the same time, understandably, limit their liability.  Pursuant to the License, Apple is not obligated to provide any maintenance, technical, or other support for the Apple Software.  Of course, evidence suggests that Apple will continue (although not required) to provide software updates and patches.  Nevertheless, the Apple Software is provided “as is” and is not subject to a warranty of any kind.  As a result, Apple is not responsible for any costs or other losses the Licensee may incur as a result of its Internal App development, use of the Apple Software, or participation in the Program.

Who can use the Apple Software? 

The Apple Software may only be used by the Licensee’s Authorized Developers.  To be an “Authorized Developer”, the developer must: (1) be an employee or authorized contractor of the Licensee; (2) have a valid registered Apple Developer account with Apple; and, (3) have a “need to know” or “need to use” the Apple Software in order to develop and test Internal Apps.

How can the Apple Software be used?

Under the License, a company may use the Apple Software under the following circumstances:

1)      To install a reasonable number of copies of the Apple Software on Apple-branded computers owned or controlled by the Licensee, to be used internally by Authorized Developers for developing or testing Internal Apps.

2)      To make and distribute a reasonable number of copies of Apple’s documentation to Authorized Developers for the sole purpose of developing or testing Internal Apps.

3)      To install one copy of the iOS on each Authorized Test Devices, up to the number of Authorized Test Devices that the Licensee has acquired licenses for, to be used for developing and testing Internal Apps. “Authorized Test Devices” are iOS Products owned or controlled by the Licensee that have been designated for testing and development purposes under the Program and specifically registered with Apple for that purpose.

4)      To distribute Provisioning Profiles to the Licensee’s employees for the purpose of developing and testing Internal Apps.

5)      To distribute Provisioning Profiles to the Licensee’s employees in conjunction with the deployment of the Internal Apps on Deployment Devices for employees’ internal use. “Deployment Devices” collectively means Authorized Test Devices and other iOS Products owned or controlled by the Licensee.

In exchange for these rights, the Licensee must make a number of representations.  The following are those representations that really should be communicated to the company’s project team while developing and deploying Internal Apps.

  • The Licensee must monitor and be responsible for its employees’ use of the Apple Software, Authorized Test Devices, and other Deployment Devices.
  • The Licensee must monitor and be responsible for use of the Internal Apps by its employees.
  • The Licensee’s Internal Apps must not violate, misappropriate, or infringe any Apple or third-party intellectual property rights.
  • The Licensee must indemnify Apple for any claim against Apple arising from its breach of the License, infringement of a third-party’s intellectual property, or use of the Apple Software.

In addition to these reps, the Licensee must adhere to a number of restrictions over its use of the Apple Software.  First, the Licensee may not install, use or, run the SDK on any non-Apple-branded computer.  Second, the Licensee may not install, use, or run the iOS and Provisioning Profiles on or in connection with devices other than Deployment Devices.  Lastly, the License does not allow the Licensee to use Apple’s trademarks or logos.  If the Licensee wishes to make reference to any Apple products or otherwise use Apple’s trademarks, then it must comply with Apple’s published guidelines for such use.

A Quick Note on Intellectual Property

Under the License, Apple of course retains ownership in all Apple Software.  The Licensee, on the other hand, retains all ownership and interest in the Internal Apps it develops using the Apple Software.  Even though the Licensee retains all ownership and interest in its Internal Apps, Apple will not treat them as confidential.  Apple expressly disclaims any confidentiality obligations or use restrictions with respect to information that a Licensee provides in connection with the Program, including its Internal Apps.  As such, Apple may use and disclose any such information on an unrestricted basis without notifying the Licensee.

To be Continued…

Part 2 will continue by describing the terms under the License that govern the apps developed and built on the Apple Software.  Finally, in Part 3, the terms governing app deployment will be addressed, as well as the unique requirements related to Apple’s Pre-release Software.