IN THE UNITED STATES DISTRICT COURT
`FOR THE EASTERN DISTRICT OF TEXAS
`TYLER DIVISION
`
`
`
`
`UNILOC USA, INC. and UNILOC
`LUXEMBOURG S.A.,
`
`
`Plaintiffs,
`
`
`v.
`
`DISTINCTIVE DEVELOPMENTS LTD.,
`
`
`Defendant.
`
`
`
`CIVIL ACTION NO. 6:12-cv-462
`
`
`
`JURY TRIAL DEMANDED
`
` §
`
`
`§
`§
`§
`§
`§
`§
`§
`§
`§
`§
`§
`
`
`PLAINTIFFS’ DISCLOSURES PURSUANT TO LOCAL PATENT RULES 3-1 AND 3-2
`
`
`
`Plaintiffs Uniloc Luxembourg S.A. and Uniloc USA, Inc. (collectively, “Uniloc”) submit
`
`these Disclosures pursuant to Local Patent Rules 3-1 and 3-2.
`
`
`
`Uniloc makes these Disclosures based on the information presently available to it.
`
`Discovery in this case has not begun and Uniloc reserves its right to amend or supplement these
`
`Disclosures as permitted by the Federal Rules of Civil Procedure, by the Local Rules of the
`
`Eastern District of Texas (including the EDTX Local Patent Rules), and by order of the Court.
`
`DISCLOSURES UNDER P.R. 3-1
`
`(a)
`
`
`
`Each claim of each patent in suit that is allegedly infringed by each opposing party.
`
`Uniloc asserts that Defendant has infringed and/or continues to infringe claim 107 of
`
`United States Patent No. 6,857,067 (the “’067 Patent”).
`
`(b)
`
`Separately for each asserted claim, each accused apparatus, product, device,
`process, method act, or other instrumentality (“Accused Instrumentality”) of each
`opposing party of which the party is aware. This identification shall be as specific
`as possible. Each product, device, and apparatus must be identified by name or
`model number, if known. Each method or process must be identified by name, if
`known, or by any product, device, or apparatus which, when used, allegedly results
`in the practice of the claimed method or process.
`
`PETITIONERS Ex. 1006 Page 1
`
`

`

`The “Accused Instrumentality” is the product activation technology used in Defendant’s
`
`
`
`Android applications, designed to run on cellular phones and/or tablet devices that require
`
`communication with a server to perform a license check to prevent unauthorized use. A list of
`
`products, which Uniloc believes uses the Accused Instrumentality, is attached as Exhibit B.
`
`Defendant has infringed and continues to infringe the asserted claim by making, using, selling,
`
`offering to sell and/or importing its products in the United States, including the Eastern District
`
`of Texas.
`
`
`
`Discovery has not started and Uniloc reserves the right supplement and/or amend these
`
`contentions as proprietary information is learned during discovery and as allowed by the Local
`
`Rules of the Eastern District of Texas, the Federal Rules of Civil Procedure, or by Order of the
`
`Court.
`
`(c) A chart identifying specifically where each element of each asserted claim is found
`within each Accused Instrumentality, including for each element that such party
`contends is governed by 35 U.S.C. §112(6), the identity of the structure(s), act(s), or
`material(s) in the Accused Instrumentality that performs the claimed function.
`
`Uniloc refers Defendant to the chart attached hereto as Exhibit A.
`
`
`
`
`(d) Whether each element of each asserted claim is claimed to be literally present or
`present under the doctrine of equivalents in the Accused Instrumentality.
`
`
`
`Uniloc asserts that each element of each asserted claim is literally present in the Accused
`
`Instrumentality. Uniloc reserves the right to assert that any particular claim element of any
`
`asserted claim also is present under the doctrine of equivalents.
`
`For any patent that claims priority to an earlier application, the priority date to
`which each asserted claim allegedly is entitled.
`
`(e)
`
`
`
`PETITIONERS Ex. 1006 Page 2
`
`

`

`
`
`The ’067 Patent did not issue from an earlier application. Uniloc contends that each of
`
`the asserted claims of the ’067 Patent is entitled to the priority date of February 26, 2001 (the
`
`application filing date).
`
`If a party claiming patent infringement wishes to preserve the right to rely, for any
`purpose, on the assertion that its own apparatus, product, device, process, method,
`act, or other instrumentality practices the claimed invention, the party must
`identify, separately for each asserted claim, each such apparatus, product, device,
`process, method, act, or other instrumentality that incorporates or reflects that
`particular claim.
`
`Uniloc does not assert that its own apparatus, product, device, process, method, act, or
`
`(f)
`
`
`
`other instrumentality practices the claimed invention.
`
`DISCLOSURES UNDER P.R. 3-2
`
`(a)
`
`
`
`(b)
`
`
`
`Documents (e.g. contracts, purchase orders, invoices, advertisements, marketing
`materials, offer letters, beta site testing, and third party or joint development
`agreements) sufficient to evidence each discussion with, disclosure to, or other
`manner of providing to a third party, or sale of or offer to sell, the claimed invention
`prior to the date of application for the patent in suit. A party’s production of a
`document as required herein shall not constitute an admission that such document
`evidences or is prior art under 35 U.S.C. §102.
`
`Uniloc is not presently aware of any responsive documents for the patent-in-suit.
`
`All documents evidencing the conception, reduction to practice, design, and
`development of each claimed invention, where were created on or before the date of
`application for the patent in suit or the priority date identified pursuant to P.R. 2-
`1(e), whichever is earlier.
`
`Uniloc is not presently aware of any responsive documents for the patent-in-suit.
`
`(c) A copy of the file history for each patent in suit.
`
`
`
`Uniloc refers Defendant to documents bates labeled Uniloc-Edelman-0000001-168,
`
`produced contemporaneously herewith.
`
`
`
`Dated: November 19, 2012
`
`
`
`Respectfully submitted,
`
`
`PETITIONERS Ex. 1006 Page 3
`
`

`

`/s/ Steven W. Hartsell
`Barry J. Bumgardner
`Lead Attorney
`Texas State Bar No. 00793424
`Steven W. Hartsell
`Texas State Bar No. 24040199
`NELSON BUMGARDNER CASTO, P.C.
`3131 West 7th Street, Suite 300
`Fort Worth, Texas 76107
`Phone: (817) 377-9111
`Fax: (817) 377-3485
`
`James Etheridge
`Texas Bar No. 24059147
`ETHERIDGE LAW GROUP, PLLC
`2600 E. Southlake Blvd., Suite 120 / 324
`Southlake, Texas 76092
`Telephone: (817) 470-7249
`Facsimile: (817) 887-5950
`Jim@EtheridgeLaw.com
`
`T. John Ward, Jr.
`Texas State Bar No. 00794818
`J. Wesley Hill
`Texas State Bar No. 24032294
`WARD & SMITH LAW FIRM
`P.O. Box 1231
`1127 Judson Road, Ste. 220
`Longview, Texas 75606-1231
`(903) 757-6400
`(903) 757-2323 (fax)
`jw@wsfirm.com
`
`ATTORNEYS FOR PLAINTIFFS
`UNILOC USA, INC. AND UNILOC
`LUXEMBOURG S.A.
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`PETITIONERS Ex. 1006 Page 4
`
`

`

`
`CERTIFICATE OF SERVICE
`
`Pursuant the Federal Rules of Civil Procedure and Local Rule CV-5(d), I certify that a
`
`true and correct copy of the foregoing was served on all counsel for Defendant by electronic mail
`
`on November 19, 2012.
`
`
`
`
`
`
`
`
`
`
`
`
`
`/s/ Steven W. Hartsell
`
`
`
`PETITIONERS Ex. 1006 Page 5
`
`

`

`EXHIBIT A
`
`
`
`Claim
`
`Accused Instrumentality – Distinctive Developments’ Product Activation Technology Used In Android Based
`Applications1
`
`107. Computer code
`executable on an electronic
`device to prevent
`unauthorized access to
`electronic data stored on
`the electronic device, the
`computer code comprising:
`
`Defendant’s applications programmed specifically for Android compatible devices using the Android Software
`Development Kit (“SDK”) contain computer code that prevents unauthorized access to said applications (i.e.,
`“computer code executable on an electronic device to prevent unauthorized access”). Specifically the
`computer code that prevents unauthorized use of Android applications is the portion of the application that
`implements a “Policy” such as the ServerManagedPolicy, and other license check functions (the “Licensing
`Code”). See Appendix A1, “Implementing a Policy”. The application is designed to be loaded onto a
`phone/tablet (i.e., “an electronic device”) operating under the control of the Android operating system. The
`
`1 This chart maps the ‘067 patent against Distinctive Developments’ Android based applications. On information and belief, products
`
`that utilize the Accused Instrumentality include, but are not limited to, products identified in Exhibit B. Thus, on information and
`belief, there are no material differences in the manner in which the Accused Instrumentality operates in Distinctive Developments’
`Android based applications, and the analysis herein is representative of Uniloc’s contentions against all products that incorporate the
`Accused Instrumentality. The use of specific examples in this chart is to help clarify Uniloc’s theory of infringement and should not
`be interpreted as limiting Uniloc’s theory of infringement to any exemplary product. To avoid any confusion, the theory of
`infringement outlined in this chart applies to all of the products listed in Exhibit B.
`
`Discovery is in its early stages. Uniloc intends to seek discovery regarding the technical operation of Distinctive Developments’
`products, including reviewing source code. Accordingly, Uniloc reserves the right to amend or supplement these contentions as
`proprietary information is obtained during the course of discovery. Uniloc expects that these contentions may be subject to
`amendment or supplementation to identify additional products and/or services released, developed, or made available after the date on
`which these contentions are served, products and/or services discontinued before the date on which these contentions are served, or of
`which Uniloc was not aware at the time of serving these contentions. Uniloc also expects that these contentions may be subject to
`amendment or supplementation to rebut allegations of non-infringement (e.g., by adding information regarding infringement under the
`
`doctrine of equivalents) or, as noted above, to include information obtained during discovery. See P.R. 3-6.
`
`PETITIONERS Ex. 1006 Page 6
`
`

`

`“data stored on the electronic device” is the functional part of the application.
`
` A
`
` non-limiting example is Rugby Nations 2011, which uses the above Licensing Code to prevent unauthorized
`access to the application. The fact that the Rugby Nations 2011 utilizes the Licensing Code is evidenced by the
`description of the application on the Google Play Store, which indicates that the application must have
`permission to initiate network communications to perform a “Market License Check” as shown below:
`
`
`PETITIONERS Ex. 1006 Page 7
`
`

`

`
`
`
`
`Figure 1 – License Check Requirement
`
`
`
`PETITIONERS Ex. 1006 Page 8
`
`

`

`code for storing license
`data on a portable licensing
`medium configured to
`communicate with the
`electronic device;
`
`When an Android based application is downloaded onto a phone or tablet (i.e., an electronic device), it is
`stored locally in memory (i.e., a portable licensing medium). Before the application is executed, it does not
`have any data cached locally that the application can reference to make a determination as to whether the
`application is licensed or not (i.e., license data). The license data includes at least one of (1) license validity
`timestamp, (2) grace period timestamp, (3) maximum retries count, and (4) update timestamp. See Appendix
`A2, “Table 3. Summary of license-management settings supplied by the Google Play server in a license
`response”.
`
` A
`
` non-limiting example is shown below wherein the file that normally contains the license data does not
`contain the necessary “shared preferences” file where the xml document containing the license data normally
`resides.
`
`
`Figure 2 – No Shared Preferences File
`
`
`
`
`
`PETITIONERS Ex. 1006 Page 9
`
`

`

`The “code for storing” is the code in the application that stores data provided by a licensing server locally in
`the SharedPreferences file (“the Locally Stored License Data”). As shown below, after execution of an
`application and communication with a licensing server, license data is stored in the shared preferences on the
`phone/tablet.
`
`
`Figure 3 -- Shared Preferences File
`
`
`
`PETITIONERS Ex. 1006 Page 10
`
`

`

`
`
`Figure 4 -- Shared Preferences File Expanded
`
`Figure 5 – Obfuscated ServerManagedPolicy xml
`
`
`
`
`
`PETITIONERS Ex. 1006 Page 11
`
`

`

`code for determining
`whether to allow access to
`the electronic data based on
`the license data;
`
`The Licensing Code inspects the at least one of (1) license validity timestamp, (2) grace period timestamp, (3)
`maximum retries count, and (4) update timestamp (i.e., license data) in the Locally Stored License Data and
`makes a decision as to whether to execute the application (i.e., the “electronic data”) or not.
`
`
`
`
`Figure 6 – Licensing Flowchart
`See Appendix A1, “Overview of license check and response”.
`
`
`
`code for verifying the
`license data stored on the
`licensing medium by
`communicating with a
`registration authority
`
`The Licensing Code periodically verifies the Locally Stored Licensing Data by initiating communications with
`the Google Play Licensing Server (i.e., registration authority). The timing of these periodic verifications is
`determined by Defendant’s specific implementation of its Policy. The licensing server collects and stores
`information about users and their devices (for example, Google account username, IMSI, and purchase
`records) (i.e., verification data). The licensing server utilizes this information to confirm whether the
`
`PETITIONERS Ex. 1006 Page 12
`
`

`

`having verification data;
`
`user/device has a valid license to run a particular Android application and returns a license response to the
`License Code. The License Code then evaluates the data contained in this response, thereby verifying the
`Locally Stored License Data.
`
`and code for providing
`updated license data
`received from the
`registration authority to the
`licensing medium.
`
`After the application queries the Google Play licensing server to perform a license check, a response is returned
`to the phone/tablet running the application that requested the license check. Assuming the user/device has a
`valid license for the application, updated values are returned for at least one of (1) license validity timestamp,
`(2) grace period timestamp, (3) maximum retries count, and (4) update timestamp. The “code for providing
`updates license data received from the registration authority” is the code in the application that stores these
`updated value(s) in memory (i.e., licensing medium) on the phone/tablet.
`
`The screen captures below demonstrate that the license data is updated when the Rugby Nations 2011
`application communicates with the Google Play license server. For example, in addition to the retryCount and
`lastResponse strings, the xml file also contains strings for retryUntil, maxRetries and validityTimestamp.
`
`PETITIONERS Ex. 1006 Page 13
`
`

`

`Figure 7 -- Shared Preferences File
`
`
`
`PETITIONERS Ex. 1006 Page 14
`
`

`

`
`Figure 8 -- Shared Preferences File Expanded
`
`
`Figure 9 -- Obfuscated xml File
`
`
`
`
`
`PETITIONERS Ex. 1006 Page 15
`
`

`

`
`
`PETITIONERS EX. 1006 Page 16
`
`PETITIONERS Ex. 1006 Page 16
`
`

`

`APPENDIX A1
`
`APPENDIX A1
`
`PETITIONERS Ex. 1006 Page 17
`
`

`

`Design
`
`Develop
`
`Distribute
`
`Training
`
`API Guides
`
`Reference
`
`Tools
`
`Adding Licensing to Your App
`
`After you've set up a publisher account and development environment (see
`Setting Up for Licensing), you are ready to add license verification to your app
`with the License Verification Library (LVL).
`
`Adding license verification with the LVL involves these tasks:
`
`1. Adding the licensing permission your application's manifest.
`2. Implementing a Policy — you can choose one of the full implementations
`provided in the LVL or create your own.
`3. Implementing an Obfuscator, if your Policy will cache any license response
`data.
`4. Adding code to check the license in your application's main Activity.
`5. Implementing a DeviceLimiter (optional and not recommended for most
`applications).
`
`The sections below describe these tasks. When you are done with the
`integration, you should be able to compile your application successfully and you
`can begin testing, as described in Setting Up the Test Environment.
`
`For an overview of the full set of source files included in the LVL, see Summary
`of LVL Classes and Interfaces.
`
`Adding the Licensing Permission
`
`To use the Google Play application for sending a license check to the server,
`your application must request the proper permission,
`com.android.vending.CHECK_LICENSE. If your application does not declare
`the licensing permission but attempts to initiate a license check, the LVL throws
`a security exception.
`To request the licensing permission in your application, declare a <uses-
`permission> element as a child of <manifest>, as follows:
`<uses-permission
`
`App Components
`
`User Interface
`
`App Resources
`
`Animation and Graphics
`
`Computation
`
`Media and Camera
`
`Location and Sensors
`
`IN THIS DOCUMENT
`Connectivity
`
`Adding the Licensing Permission
`Text and Input
`Implementing a Policy
`Data Storage
`Guidelines for custom policies
`ServerManagedPolicy
`Administration
`StrictPolicy
`Web Apps
`Implementing an Obfuscator
`AESObfuscator
`Best Practices
`Checking the License from an
`Activity
`Google Services
`Overview of license check and
`response
`In-app Billing
`Add imports
`Application Licensing
`Implement
`Licensing Overview
`LicenseCheckerCallback as a
`private inner class
`Setting Up for Licensing
`Create a Handler for posting
`Adding Licensing to Your
`from LicenseCheckerCallback to
`App
`the UI thread
`Instantiate LicenseChecker and
`LicenseCheckerCallback
`Call checkAccess() to initiate the
`license check
`Embed your public key for
`licensing
`Call your LicenseChecker's
`onDestroy() method to close IPC
`connections
`Implementing a DeviceLimiter
`Obfuscating Your Code
`Publishing a Licensed Application
`Removing Copy Protection
`
`PETITIONERS Ex. 1006 Page 18
`
`

`

`android:name="com.android.vending.CHECK_LICENSE">
`For example, here's how the LVL sample application declares the permission:
`
`Where to Get Support
`
`<?xml version="1.0" encoding="utf-8"?>
`
`<manifest xmlns:android="http://schemas.android.com/apk/res/android" ...">
` <!-- Devices >= 3 have version of Google Play that supports licensing. -->
` <uses-sdk android:minSdkVersion="3" />
` <!-- Required permission to check licensing. -->
` <uses-permission android:name="com.android.vending.CHECK_LICENSE" />
` ...
`</manifest>
`
`Note: Currently, you cannot declare the CHECK_LICENSE permission in the LVL library project's manifest, because the
`SDK Tools will not merge it into the manifests of dependent applications. Instead, you must declare the permission in
`each dependent application's manifest.
`
`ServerManagedPolicy
`
`The LVL includes a complete Policy
`implementation called
`ServerManagedPolicy that makes use
`of license-management settings
`provided by the Google Play server.
`
`Implementing a Policy
`
`Google Play licensing service does not itself determine whether a given user
`with a given license should be granted access to your application. Rather,
`that responsibility is left to a Policy implementation that you provide in your
`application.
`
`Use of ServerManagedPolicy as the
`basis for your Policy is strongly
`recommended. For more information,
`see ServerManagedPolicy section,
`below.
`
`Policy is an interface declared by the LVL that is designed to hold your
`application's logic for allowing or disallowing user access, based on the result
`of a license check. To use the LVL, your application must provide an
`implementation of Policy.
`The Policy interface declares two methods, allowAccess() and
`processServerResponse(), which are called by a LicenseChecker
`instance when processing a response from the license server. It also declares
`an enum called LicenseResponse, which specifies the license response
`value passed in calls to processServerResponse().
`processServerResponse() lets you preprocess the raw response data received from the licensing server, prior to
`determining whether to grant access.
`A typical implementation would extract some or all fields from the license response and store the data locally to a
`persistent store, such as through SharedPreferences storage, to ensure that the data is accessible across
`application invocations and device power cycles. For example, a Policy would maintain the timestamp of the last
`successful license check, the retry count, the license validity period, and similar information in a persistent store, rather
`than resetting the values each time the application is launched.
`When storing response data locally, the Policy must ensure that the data is obfuscated (see Implementing an
`Obfuscator, below).
`allowAccess() determines whether to grant the user access to your application, based on any available license
`
`PETITIONERS Ex. 1006 Page 19
`
`

`

`response data (from the licensing server or from cache) or other application-specific information. For example, your
`implementation of allowAccess() could take into account additional criteria, such as usage or other data retrieved
`from a backend server. In all cases, an implementation of allowAccess() should only return true if the user is
`licensed to use the application, as determined by the licensing server, or if there is a transient network or system
`problem that prevents the license check from completing. In such cases, your implementation can maintain a count of
`retry responses and provisionally allow access until the next license check is complete.
`To simplify the process of adding licensing to your application and to provide an illustration of how a Policy should be
`designed, the LVL includes two full Policy implementations that you can use without modification or adapt to your needs:
`ServerManagedPolicy, a flexible Policy that uses server-provided settings and cached responses to manage access
`across varied network conditions, and
`StrictPolicy, which does not cache any response data and allows access only if the server returns a licensed response.
`
`For most applications, the use of ServerManagedPolicy is highly recommended. ServerManagedPolicy is the LVL default
`and is integrated with the LVL sample application.
`
`Guidelines for custom policies
`In your licensing implementation, you can use one of the complete policies provided in the LVL (ServerManagedPolicy or
`StrictPolicy) or you can create a custom policy. For any type of custom policy, there are several important design points to
`understand and account for in your implementation.
`
`The licensing server applies general request limits to guard against overuse of resources that could result in denial of
`service. When an application exceeds the request limit, the licensing server returns a 503 response, which gets passed
`through to your application as a general server error. This means that no license response will be available to the user
`until the limit is reset, which can affect the user for an indefinite period.
`If you are designing a custom policy, we recommend that the Policy:
`1. Caches (and properly obfuscates) the most recent successful license response in local persistent storage.
`2. Returns the cached response for all license checks, for as long as the cached response is valid, rather than making a
`request to the licensing server. Setting the response validity according to the server-provided VT extra is highly
`recommended. See Server Response Extras for more information.
`3. Uses an exponential backoff period, if retrying any requests the result in errors. Note that the Google Play client
`automatically retries failed requests, so in most cases there is no need for your Policy to retry them.
`4. Provides for a "grace period" that allows the user to access your application for a limited time or number of uses, while
`a license check is being retried. The grace period benefits the user by allowing access until the next license check can
`be completed successfully and it benefits you by placing a hard limit on access to your application when there is no
`valid license response available.
`Designing your Policy according to the guidelines listed above is critical, because it ensures the best possible
`experience for users while giving you effective control over your application even in error conditions.
`Note that any Policy can use settings provided by the licensing server to help manage validity and caching, retry grace
`period, and more. Extracting the server-provided settings is straightforward and making use of them is highly
`recommended. See the ServerManagedPolicy implementation for an example of how to extract and use the extras. For a
`list of server settings and information about how to use them, see Server Response Extras.
`
`ServerManagedPolicy
`The LVL includes a full and recommended implementation of the Policy
`
`PETITIONERS Ex. 1006 Page 20
`
`

`

`interface called ServerManagedPolicy. The implementation is integrated with
`the LVL classes and serves as the default Policy in the library.
`ServerManagedPolicy provides all of the handling for license and retry
`responses. It caches all of the response data locally in a
`SharedPreferences file, obfuscating it with the application's Obfuscator
`implementation. This ensures that the license response data is secure and
`persists across device power cycles. ServerManagedPolicy provides concrete
`implementations of the interface methods processServerResponse() and
`allowAccess() and also includes a set of supporting methods and types
`for managing license responses.
`
`Server Response Extras
`
`For certain types of licensing
`responses, the licensing server
`appends extra settings to the
`responses, to help the application
`manage licensing effectively.
`
`See Server Response Extras for a list
`of settings and
`ServerManagedPolicy.java for
`information about how a Policy can
`use the extras.
`
`Importantly, a key feature of ServerMangedPolicy is its use of server-provided
`settings as the basis for managing licensing across an application's refund
`period and through varying network and error conditions. When an application contacts the Google Play server for a
`license check, the server appends several settings as key-value pairs in the extras field of certain license response types.
`For example, the server provides recommended values for the application's license validity period, retry grace period, and
`maximum allowable retry count, among others. ServerManagedPolicy extracts the values from the license response in its
`processServerResponse() method and checks them in its allowAccess() method. For a list of the server-provided
`settings used by ServerManagedPolicy, see Server Response Extras.
`
`For convenience, best performance, and the benefit of using license settings from the Google Play server, using
`ServerManagedPolicy as your licensing Policy is strongly recommended.
`If you are concerned about the security of license response data that is stored locally in SharedPreferences, you can
`use a stronger obfuscation algorithm or design a stricter Policy that does not store license data. The LVL includes an
`example of such a Policy — see StrictPolicy for more information.
`To use ServerManagedPolicy, simply import it to your Activity, create an instance, and pass a reference to the instance
`when constructing your LicenseChecker. See Instantiate LicenseChecker and LicenseCheckerCallback for more
`information.
`
`StrictPolicy
`The LVL includes an alternative full implementation of the Policy interface called StrictPolicy. The StrictPolicy
`implementation provides a more restrictive Policy than ServerManagedPolicy, in that it does not allow the user to access
`the application unless a license response is received from the server at the time of access that indicates that the user is
`licensed.
`
`The principal feature of StrictPolicy is that it does not store any license response data locally, in a persistent store.
`Because no data is stored, retry requests are not tracked and cached responses can not be used to fulfill license checks.
`The Policy allows access only if:
`The license response is received from the licensing server, and
`The license response indicates that the user is licensed to access the application.
`
`Using StrictPolicy is appropriate if your primary concern is to ensure that, in all possible cases, no user will be allowed to
`access the application unless the user is confirmed to be licensed at the time of use. Additionally, the Policy offers slightly
`more security than ServerManagedPolicy — since there is no data cached locally, there is no way a malicious user could
`tamper with the cached data and obtain access to the application.
`
`PETITIONERS Ex. 1006 Page 21
`
`

`

`At the same time, this Policy presents a challenge for normal users, since it means that they won't be able to access the
`application when there is no network (cell or Wi-Fi) connection available. Another side-effect is that your application will
`send more license check requests to the server, since using a cached response is not possible.
`
`Overall, this policy represents a tradeoff of some degree of user convenience for absolute security and control over
`access. Consider the tradeoff carefully before using this Policy.
`To use StrictPolicy, simply import it to your Activity, create an instance, and pass a reference to it when constructing your
`LicenseChecker. See Instantiate LicenseChecker and LicenseCheckerCallback for more information.
`
`Implementing an Obfuscator
`
`AESObfuscator
`
`A typical Policy implementation needs to save the license response data for
`an application to a persistent store, so that it is accessible across application
`invocations and device power cycles. For example, a Policy would maintain
`the timestamp of the last successful license check, the retry count, the license
`validity period, and similar information in a persistent store, rather than
`resetting the values each time the application is launched. The default
`Policy included in the LVL, ServerManagedPolicy, stores license response
`data in a SharedPreferences instance, to ensure that the data is
`persistent.
`Because the Policy will use stored license response data to determine
`whether to allow or disallow access to the application, it must ensure that any
`stored data is secure and cannot be reused or manipulated by a root user on
`a device. Specifically, the Policy must always obfuscate the data before
`storing it, using a key that is unique for the application and device.
`Obfuscating using a key that is both application-specific and device-specific is critical, because it prevents the obfuscated
`data from being shared among applications and devices.
`
`The LVL includes a full Obfuscator
`implementation in the
`AESObfuscator.java file. The
`Obfuscator uses AES encryption to
`obfuscate/unobfuscate data. If you are
`using a Policy (such as
`ServerManagedPolicy) that caches
`license response data, using
`AESObfuscator as basis for your
`Obfuscator implementation is highly
`recommended.
`
`The LVL assists the application with storing its license response data in a secure, persistent manner. First, it provides an
`Obfuscator interface that lets your application supply the obfuscation algorithm of its choice for stored data. Building on
`that, the LVL provides the helper class PreferenceObfuscator, which handles most of the work of calling the application's
`Obfuscator class and reading and writing the obfuscated data in a SharedPreferences instance.
`The LVL provides a full Obfuscator implementation called AESObfuscator that uses AES encryption to obfuscate data.
`You can use AESObfuscator in your application without modification or you can adapt it to your needs. For more
`information, see the next section.
`
`AESObfuscator
`The LVL includes a full and recommended implementation of the Obfuscator interface called AESObfuscator. The
`implementation is integrated with the LVL sample application and serves as the default Obfuscator in the library.
`AESObfuscator provides secure obfuscation of data by using AES to encrypt and decrypt the data as it is written to or
`read from storage. The Obfuscator seeds the encryption using three data fields provided by the application:
`1. A salt — an array of random bytes to use for each (un)obfuscation.
`2. An application identifier string, typically the package name of the application.
`3. A device identifier string, derived from as many device-specific sources as possible, so as to make it as unique.
`
`PETITIONERS Ex. 1006 Page 22
`
`

`

`To use AESObfuscator, first import it to your Activity. Declare a private static final array to hold the salt bytes and initialize
`it to 20 randomly generated bytes.
`
` ...
` // Generate 20 random bytes, and put them here.
` private static final byte[] SALT = new byte[] {
` -46, 65, 30, -128, -103, -5