Category Archives: Software

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.

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.

Security

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 (http://dev.twitter.com).

  • 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.