`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`
`____________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
` ____________
`
`UBISOFT, INC. AND SQUARE ENIX, INC.,
`Petitioners,
`
`v.
`
`UNILOC USA, INC. AND UNILOC LUXEMBOURG, S.A.,
`Patent Owners.
`
`____________
`
`Case No. IPR2017-01291
`U.S. Patent No. 6,728,766
` ____________
`
`
`
`PETITION FOR INTER PARTES REVIEW
`
`OF U.S. PATENT NO. 6,728,766
`
`
`
`
`
`
`
`

`

`TABLE OF CONTENTS
`
`INTRODUCTION ............................................................................................ 1
`I.
`II. REQUIREMENTS FOR INTER PARTES REVIEW UNDER 37 C.F.R.
`§ 42.104 ............................................................................................................. 1
`A. Grounds for Standing Under 37 C.F.R. §42.104(a) .................................... 1
`B. Identification of Challenge Under 37 C.F.R. §42.104(b) and Relief
`Requested .................................................................................................... 1
`C. Level of Ordinary Skill in the Art ............................................................... 2
`D. Claim Construction ..................................................................................... 2
`1. “means for maintaining license management policy information”
`(Claim 7) ..................................................................................................... 3
`2. “means for receiving at the license management server a request for a
`license availability of a selected one of a plurality of application programs
`from a user at a client” (Claim 7) ............................................................... 3
`3. “means for determining the license availability for the selected one of
`the plurality of application programs for the user based on the maintained
`license management policy information” (Claim 7) ................................... 4
`4. “means for providing an unavailability indication to the client
`responsive to the selection if the license availability indicates that a
`license is not available for the user or an availability indication if the
`licensed availability indicates that a license is available for the user”
`(Claim 7) ..................................................................................................... 4
`III. OVERVIEW OF THE ‘766 PATENT .............................................................. 5
`A. Description of the Alleged Invention of the ‘766 Patent ............................ 5
`B. Prosecution History of the ‘766 Patent ....................................................... 6
`IV. THERE IS A REASONABLE LIKELIHOOD THAT THE CHALLENGED
`CLAIMS ARE UNPATENTABLE .................................................................. 8
`A. Olsen Anticipates Claims 1, 3, 7, 9, 13, and 15 Under §102(a) and (e) ..... 8
`V. MANDATORY NOTICES UNDER 37 C.F.R. § 42.8(A)(1) ........................ 32
`A. Real Party-In-Interest and Related Matters ............................................... 32
`B. Lead and Back-Up Counsel Under 37 C.F.R. § 42.8(b)(3) ...................... 32
`C. Payment of Fees Under 37 C.F.R. § 42.103 ............................................. 33
`
`
`
` 2
`
`

`

`VI. CONCLUSION ............................................................................................... 33
`
`VI. CONCLUSION ............................................................................................. .. 33
`
`
`
` 3
`
`

`

`I.
`
`INTRODUCTION
`
`Ubisoft, Inc. and Square Enix, Inc. (“Petitioners”) requests Inter Partes
`
`Review (“IPR”) of claims 1, 3, 7, 9, 13, and 15 (“the Challenged Claims”) of U.S.
`
`Patent No. 6,728,766 (“‘766 Patent”). EX1001.
`
`II. REQUIREMENTS FOR INTER PARTES REVIEW UNDER 37 C.F.R.
`§ 42.104
`A. Grounds for Standing Under 37 C.F.R. §42.104(a)
`Petitioners certify that the ‘766 Patent is available for IPR and that no
`
`Petitioner is barred or estopped from requesting this IPR. Specifically, each
`
`Petitioner states it: (1) is not the owner of the ‘766 Patent; (2) has not filed a civil
`
`action challenging the validity of any claim of the ‘766 Patent; (3) this Petition is
`
`timely filed less than one year after it was served with a complaint alleging
`
`infringement of the ‘766 Patent; and (4) this Petition is filed more than nine
`
`months after the ‘766 Patent issued.
`
`B.
`
`Identification of Challenge Under 37 C.F.R. §42.104(b) and Relief
`Requested
`
`In view of the prior art, evidence, and discussion of claim limitations below,
`
`the Challenged Claims of the ‘766 Patent are unpatentable and should be cancelled.
`
`37 C.F.R. §42.104(b)(1). The review of the Challenged Claims of the ‘766 Patent
`
`is governed by pre-AIA 35 U.S.C. §§102 and 103.
`
`
`
` 1
`
`

`

`Proposed Statutory Rejections for the ‘646 Patent
`
`Claims: 1, 3, 7, 9, 13, and 15 are Anticipated under §§102(a) and/or (e) by US
`
`5,758,069 (“Olsen”) [EX1002]
`
`
`C. Level of Ordinary Skill in the Art
`Petitioners contend that a person of ordinary skill in the field of computer
`
`networking at the time of the alleged invention, December 14, 1998, (“POSITA”)
`
`would have had at least an undergraduate degree in computer science, computer
`
`engineering, or a related field or an equivalent number of years of working
`
`experience and at least one to two years of experience in networking environments,
`
`including at least some experience with management of application programs in a
`
`network environment.
`
`D. Claim Construction
`A claim subject to IPR receives the “broadest reasonable construction in
`
`light of the specification of the patent in which it appears.” 37 C.F.R. §42.100(b).
`
`Unless otherwise noted below, Petitioners propose, for purposes of this proceeding
`
`only, that the claim terms of the ‘766 Patent are presumed to take on their ordinary
`
`and customary meaning that the term would have to one of ordinary skill in the art.
`
`The claim construction analysis is not, and should not be viewed as a concession
`
`by Petitioners as to the proper scope of any claim term in litigation. These
`
`assumptions are not a waiver of any argument in any litigation that claim terms in
`
`
`
` 2
`
`

`

`the ‘766 Patent are indefinite or otherwise invalid or unpatentable. Claim 7
`
`includes recitations in means-plus-function form. Petitioner proposes that each of
`
`the below phrases is governed by 35 U.S.C. § 112, ¶6 (now 35 U.S.C. § 112(f))
`
`and proposes the following constructions:
`
`1.
`
`for maintaining
`“means
`information” (Claim 7)
`
`license management policy
`
`
`
`The stated function is “maintaining license management policy information
`
`for a plurality of application programs at a license management server, the license
`
`management policy information including at least one of a user identity based
`
`policy, an administrator policy override definition or a user policy override
`
`definition.” The disclosed structure is a database and equivalents thereof. EX1001,
`
`‘766 Patent at 12:50-52 (“server system 22 stores license use management policy
`
`information in a hierarchal centralized preference database 208”), 5:40-42.
`
`2.
`
`“means for receiving at the license management server a
`request for a license availability of a selected one of a
`plurality of application programs from a user at a client”
`(Claim 7)
`
`
`
`The stated function is “receiving at the license management server a request
`
`for a license availability of a selected one of a plurality of application programs
`
`from a user at a client.” The disclosed structure is server 22 that is programmed to
`
`“receive[] a request to initiate execution of the application program,” the request
`
`
`
` 3
`
`

`

`including “an identification of the user who initiated the request,” and equivalents
`
`thereof. Id. at 10:6-11; see also id. at 10:66-67, 11:3-8.
`
`
`
`3.
`
`“means for determining the license availability for the
`selected one of the plurality of application programs for the
`user based on the maintained license management policy
`information” (Claim 7)
`
`
`
`The stated function is “determining the license availability for the selected
`
`one of the plurality of application programs for the user based on the maintained
`
`license management policy information.” The disclosed structure to perform this
`
`function is server 22 programmed to “determine if the user is an authorized user
`
`for the application program,” and equivalents thereof. Id. at 10:9-10; see also id. at
`
`10:6-15, 4:62-67, 11:3-8, Fig. 3 (block 78).
`
`4.
`
`“means for providing an unavailability indication to the client
`responsive to the selection if the license availability indicates
`that a license is not available for the user or an availability
`indication if the licensed availability indicates that a license is
`available for the user” (Claim 7)
`
`
`
`The stated function is “providing an unavailability indication to the client
`
`responsive to the selection if the license availability indicates that a license is not
`
`available for the user or an availability indication if the licensed availability
`
`indicates that a license is available for the user.” The ‘766 Patent discloses only
`
`that the “license management server” determines “license availability” based on
`
`“maintained license management policy information”, and an application launcher
`
`program to which “the availability or unavailability indication may be provided.”
`
`
`
` 4
`
`

`

`Id. at 5:42-61. The ‘766 Patent, however, incorporates by reference U.S. Patent
`
`No. 6,510,466 (EX1001 at 7:17-21, 11:27-30), which discloses:
`
`“If the requesting user is an authorized user for the requested application,
`the server system 22 accepts a license request from the application (block
`288). If no licenses are available, the system may be configured to provide
`an error message display and stop processing (block 286). The error
`message may take the form of an unavailability indication provided to client
`station 202 if the license availability information obtained from a license
`management server, which may be system server 22 or other another server
`on the network, indicates no licenses are available for the requesting user. If
`a license is available, an instance of the requested application is executed
`and error and trace logging operations are enabled to receive error and
`trace log entries if they are sent from the application (block 290).”
`
`EX1003, ‘466 Patent at 16:43-56; see also id. at Fig. 7 (steps 288, 286, 290).
`
`Accordingly, the disclosed structure corresponding to the function is server system
`
`22 programmed to provide an error message if no licenses are available and to
`
`allow execution of the requested application if a license is available, and
`
`equivalents thereof. Id.
`
`III. OVERVIEW OF THE ‘766 PATENT
`A. Description of the Alleged Invention of the ‘766 Patent
`The ‘766 Patent was filed on April 10, 2001 and claims priority to US Patent
`
`No. 6,324,578 (EX1004), filed on December 14, 1998. The ‘766 Patent describes
`
`methods and systems for management of configurable application programs on a
`
`
`
` 5
`
`

`

`network. EX1001, 1:22-24, 3:40-45. In particular, an on-demand license
`
`management server maintains license management policy information for a
`
`plurality of applications at a server database. Id. at 12:50-59, 5:38-60. The license
`
`management server receives a request to initiate execution of an application
`
`program and determines if the user is an authorized user for the application
`
`program. Id. at 10:1-12. Based on the determination, the license management
`
`server either provides an “unavailability indication” or an “availability indication”
`
`to the requesting client. Id. at 5:44-52.
`
`Prosecution History of the ‘766 Patent
`
`B.
`The ‘766 Patent was filed on April 10, 2001 with 25 claims. See EX1005,
`
`‘766 FH at As-Filed Claims. The Examiner rejected claims 19-22, 25-29 under
`
`§103(a) as obvious over Christiano and claims 20, 26, and 28 under §103(a) as
`
`obvious over Christiano in view of Franklin. Id. at 5/6/02 Rejection.
`
`In response, Applicants amended claims 19, 22, and 25 to recite “the license
`
`management policy information including at least one of a user identity based
`
`policy, an administrator policy override definition or a user policy override
`
`definition” Id. at 8/1/02 Amendment, pp.13-14. Applicants also added new claims
`
`30-32. Id. at p.6. Applicants distinguished the claimed invention by arguing that
`
`Christiano did not disclose a “user identity based” license policy or policies that
`
`allowed “administrator or user overrides.” Applicants further argued:
`
`
`
` 6
`
`

`

`“Christiano describes license policies as follows: […]
`
`Thus, Christiano does not appear to disclose or suggest license policies that
`are user identity based, or policies that allow administrator or user
`overrides.”
`
`Id. at p.7.
`
`The Examiner subsequently issued a Final Rejection of all pending claims.
`
`The Examiner rejected claims 19-22 and 25-32 under §103(a) as obvious over
`
`Christiano in view of Duvvoori and Wyman. Id. at 11/1/02 Rejection.
`
`In response, Applicants argued that the Examiner’s references “appear to
`
`relate to management of licenses based on requesting clients or computers or
`
`applications, not based on requesting users.” Id. at 1/27/03 Amendment.
`
`Applicants also added new claims 33-38.
`
`Applicants appealed the Final Rejection and argued: “Christiano, Duvvoori,
`
`and Wyman manage licenses by computer or node, not by a user.” Id. at 4/15/03
`
`Appeal Brief, p.6. Applicants further argued:
`
`“In contrast, the present invention associates license requests with users. By
`associating license requests and grants with a logged in user, a user may,
`for example, move between different computers while maintaining a license.
`Furthermore, as described with reference to the types of license policies
`associated with the application, the license management may be customized
`at a user level.”
`
`Id.
`
`
`
` 7
`
`

`

`The Examiner subsequently issued a Non-Final Office action, rejecting
`
`claims 19, 21, 22, 25, 27, and 29-38 under §103(a) as obvious over Christiano in
`
`view of Duvvoori and Wyman. Id. at 6/30/03 Office Action.
`
`In response, Applicants filed a response, arguing: “[T]he discussed
`
`“requestor” is clearly the computer, not a user logged onto the computer. The
`
`Office Action does not otherwise address the grounds for patentability related to
`
`the distinction between user based and computer based license management as
`
`raised in the Brief on Appeal.” Id. at 9/29/03 Request for Reconsideration.
`
`A Notice of Allowance subsequently issued noting that the claims were
`
`allowable over the prior art of record “in light of Applicants’ arguments.” Id. at
`
`12/12/03 Notice of Allowance.
`
`IV. THERE
`IS A REASONABLE LIKELIHOOD THAT THE
`CHALLENGED CLAIMS ARE UNPATENTABLE
`
`The following prior art reference discloses each limitation of the Challenged
`
`Claims. As such, these claims are unpatentable. Included below are exemplary
`
`citations to the prior art reference.
`
`A. Olsen Anticipates Claims 1, 3, 7, 9, 13, and 15 Under §102(a) and
`(e)
`
`Olsen was filed March 15, 1996, issued May 26, 1998, and is therefore prior
`
`art under at least §§102(a) and (e). Olsen and the ‘766 Patent each relate to
`
`computer network management and application program management. EX1002,
`
`
`
` 8
`
`

`

`Olsen at Abstract, 2:31-43. Olsen, like the ‘766 Patent, discloses a method and
`
`system for license management on a network. EX1002 at 4:34-52, 8:29-42.
`
`Claim 1. A method for license use management for a network comprising the
`steps of:
`
`Like the ‘766 Patent, Olsen teaches a method of controlling how many users
`
`can use an application (i.e., license use management) for a network.
`
`“An electronic licensing system according to various aspects of the present
`invention provides alternative methods and apparatus for licensing software
`in a network environment. License information is suitably stored in a
`distributed database among several servers. The license information may be
`coupled with any suitable attributes to create a desired licensing policy.
`Clients are equipped with a suitable library of application programming
`interfaces (APIs) for acquiring and managing licenses. To request an
`application, the client assembles a request having the desired license
`criteria, such as the publisher, product, version, and number of license units.
`This information is provided with other relevant information, such as the
`user’s name.”
`
`EX1002, Olsen at 2:31-43.
`
`“When a license is installed in LSP 110, the administrator may assign a
`license to an individual, machine, group, container, or other selected users.
`The license certificate is then only available to a user with a security
`assignment corresponding to the certificate. The assignments are suitably
`additive, such that multiple groups, machines, users, or containers may be
`assigned to a single certificate.”
`
`
`
` 9
`
`

`

`Id. at 8:29-35; see also id. at 1:5-7, Abstract, 2:44-54, 3:43-61, 4:30-52; also
`
`compare with EX1001, ‘766 Patent at 3:26-27 (“License use management typically
`
`involves controlling how may users can use an application.”).
`
`[1(a)] maintaining license management policy information for a plurality of
`application programs at a
`license management server,
`the
`license
`management policy information including at least one of a user identity based
`policy, an administrator policy override definition or a user policy override
`definition;
`
`The ‘766 Patent discloses that the license management policy information
`
`need include only one of (i.e., at least one of) the claimed user identity based
`
`policy, administrator policy override definition or a user policy override definition.
`
`See, e.g., id. at Claim 5 (“The method of claim 1 wherein the at least one of a user
`
`identity based policy, an administrator policy override definition or a user policy
`
`override definition comprises a user identity based policy associated with a group
`
`of users.”). Further, the ‘766 Patent describes “a user identity based policy” as, for
`
`example, a policy for a specific user or a group of users. See, e.g., EX1001, ‘766
`
`Patent at 13:22-25.
`
`Olsen
`
`teaches maintaining
`
`license certificate
`
`records
`
`(i.e.,
`
`license
`
`management policy information) for application programs in a license certificate
`
`database 112 on “at least one server 104” (i.e., license management server).
`
`EX1002, Olsen at 3:43-59, 4:30-52, 5:11-34, 8:12-20, 10:43-49; see also id. at Fig.
`
`1. Each license certificate record includes, for example, fundamental information
`
`
`
` 10
`
`

`

`relating to the license (e.g., product name, version, number of license units, start
`
`date, expiration date), in addition to other “policy attributes”:
`
`“The license information stored in license certificate database 112 is
`suitably stored in a format common to each license. Referring now to FIG. 3,
`a suitable format for a license record 302 comprises an identifier field 304,
`a data length field 306, and a data field 308.”
`
`Id. at 5:35-40; see also id. at 5:40-64, Fig. 3.
`
`“As described above, various policy attributes for a license are stored in
`data field 308 associated with a particular license certificate. Data field 308
`of each license record 302 installed in license certificate database 112
`suitably stores a first group of information comprising required entries, and
`a second group of information comprising optional entries. The structure of
`the required entries is suitably common among each of the license
`certificates. The required entries describe
`the application's basic
`information. The optional entries, on the other hand, provide system specific
`enhancements to the standard policy.
`
`The required entries suitably include fundamental information relating to
`the license certificate. For example, the required entries suitably include the
`publisher name, product name, version, number of license units, start date,
`and expiration date. The required entries also suitably include a unique
`identifier, such as a license or serial number, to distinguish the license from
`other licenses provided by the same publisher, product, and version. The
`required entries may also be configured to include various policy attributes
`to handle the consumption of license units and error conditions. A set of
`policy attributes may be included in the optional entries to describe various
`
`
`
` 11
`
`

`

`parameters of the license certificate. The policy attributes stored in data
`field 308 facilitate the detailed and flexible description of the license terms
`and conditions, for example including a number of license units tag, a
`default units to consume tag, or a default metered tag.”
`
`Id. at 9:22-50; see also id. at 9:50-10:42.
`
`Like the ‘766 Patent, Olsen discloses that a license certificate record may be
`
`assigned to a specific user or a group of users (i.e., includes a user identity based
`
`policy).
`
`“When a license is installed in LSP 110, the administrator may assign a
`license to an individual, machine, group, container, or other selected users.
`The license certificate is then only available to a user with a security
`assignment corresponding to the certificate. The assignments are suitably
`additive, such that multiple groups, machines, users, or containers may be
`assigned to a single certificate.”
`
`Id. at 8:29-35; see also id. at 8:20-28, 4:34-52, 10:12-30. See also Olsen applied to
`
`Elements 7(a) and 13(a).
`
`[1(b)] receiving at the license management server a request for a license
`availability of a selected one of the plurality of application programs from a
`user at a client;
`
`Olsen discloses that server 104 receives a request for a license to a specified
`
`application program (i.e., for a license availability of a selected one of the plurality
`
`of application programs) from a user at a client 106:
`
`“Server 104 includes a LSP 110 for performing license transactions and a
`license certificate database 112. LSP 110 performs several licensing
`
`
`
` 12
`
`

`

`functions, for example receiving requests from clients 106 and maintaining
`and searching license certificate database 112 to create license certificate
`objects. LSP 110 may be implemented in software, suitably comprising a
`NetWare Loadable Module in the Novell NetWare 4.1 environment.”
`
`EX1002, Olsen at 3:54-61; see also id. at 3:62-4:3.
`
`“After the license certificates have been added to license certificate
`database 112 and stored in buffer format, client 106 may request licenses
`for access to applications. Referring now to FIGS. 8A-B, when the user
`desires an application, the user suitably chooses a license by selecting a
`name from a list or an icon, and then provides suitable information
`corresponding to any required fields (step 802). …
`
`If licensing system 100 is available, client 106 bundles the request
`arguments for the function, along with a function number, into a buffer, and
`uses the RPC mechanism furnished by the client provider to send the request
`to LSP 110 (step 808). The request is generated using the license acquisition
`API and suitably specifies particular information relating to the application,
`such as the publisher, product, and version for which license units are
`requested. In addition, the API suitably indicates the number of license units
`requested, so that the number of units consumed is specified by the API.
`Client 106 transmits the request to LSP 110 and waits for a response.
`
`LSP 110 receives the request for a number of license units from client 106
`(step 810). … The handler 202 of LSP 110 receives the request and
`transmits it to parser 204. Parser 204 transmits the parsed request to
`implementation translator 206, which decodes the request. The request is
`transmitted to transaction tracking system 210, which grants a licensing
`handle describing the start of a new transaction (step 812).”
`
`
`
` 13
`
`

`

`Id. at 10:43-11:9.
`
`“To request an application, the client assembles a request having the
`desired license criteria, such as the publisher, product, version, and number
`of license units. This information is provided with other relevant information,
`such as the user's name.
`
`When the request for a license to an application is received by a local server,
`the server searches the local database for license information which satisfies
`the request criteria.”
`
`Id. at 2:38-47; see also id. at 6:6-32, 2:37-47, 3:54-4:2, 4:23-52, 8:20-35, 10:12-30,
`
`11:40-46.
`
`Id. at Fig. 1.
`
`
`
`
`
` 14
`
`

`

`Id. at Fig. 8A (step 802 and 810). See also Olsen applied to Elements 7(b) and
`
`
`
`13(b).
`
`[1(c)] determining the license availability for the selected one of the plurality
`of application programs for the user based on the maintained license
`management policy information; and
`
`Olsen discloses that, upon receiving a request for a license, a database access
`
`system 208 of server 104 creates a “certificate database object” to search the
`
`
`
` 15
`
`

`

`license certificate database 112 and determine whether the license units of the
`
`requested application program’s license certificate record are available to the
`
`requesting user. If license units are available and the license certificate indicates
`
`that the policy is assigned (see EX1002, Olsen at 8:20-35; also Element 1(a)), the
`
`license certificate object performs a “security equivalency check” to determine
`
`whether the requesting user is among those assigned to the license certificate by
`
`reviewing “the user information associated with the request” and “any existing
`
`license assignments,” among other information (i.e., determining the license
`
`availability … for the user based on the maintained license management policy
`
`information):
`
`“Implementation translator 206 also provides the decoded request to
`database access system 208, which creates a certificate database object to
`search license certificate database 112 (step 814). The certificate database
`object uses the information from implementation translator 206 to find units
`conforming to the request criteria. For example, the certificate database
`object suitably receives a combination of publisher name, product name,
`version, and license handle. The certificate database object searches the
`local license certificate database 112 for one or more license certificates
`which could fulfill the request, i.e., relate to the appropriate application
`(step 816). The user’s login information is suitably used for accessing the
`various license records in the database. The certificate database object
`provides direct access to each license record without regard to the
`underlying certificate’s policy attributes. The certificate database object
`
`
`
` 16
`
`

`

`selects a first license record and determines whether the license record is
`compatible with the request. If so, the certificate database object creates a
`license certificate object using the information in the buffer. The license
`certificate object
`suitably determines whether
`the
`license units
`corresponding to the license record are available to the requesting client by
`reviewing, for example, the policy attributes of the license, the user
`information associated with the request, any existing license assignments,
`and the raw number of units originally installed. This is performed before
`actually obtaining the license to determine whether all of the required
`license units are available.
`
`The certificate database object checks each license record in the database
`until sufficient records are accumulated. If compatible license records are
`found in the present database, LSP 110 constructs license certificate objects
`from the buffers matching the publisher, product, and version fields (step
`826). The license certificate objects are queried to determine whether
`enough units have been accumulated to fulfill the request (step 818). If the
`request cannot be fulfilled using the local databases, the certificate database
`object is transmitted to other available LSPs 110 (step 820). …
`
`If all of the available LSPs 110 have been searched (step 822) and the
`appropriate license units cannot be located, LSP 110 returns an error
`message to client 106 (step 824). If the appropriate buffers are available
`among the various LSPs, the license certificate objects consume the detected
`license units. To consume the units, each license certificate object checks the
`license information for any existing assignments. If an assignment exists on
`the license certificate, it performs a security equivalency check to determine
`
`
`
` 17
`
`

`

`whether the requesting client 106 is among those assigned to the license
`certificate (step 828).”
`
`Id. at 11:21-12:17; see also id. at 10:45-49 (“Referring now to FIGS. 8A-B, when
`
`the user desires an application, the user suitably chooses a license by selecting a
`
`name from a list or an icon, and then provides suitable information corresponding
`
`to any required fields (step 802).”), 8:29-35 (reproduced in Element 1(a)), 9:22-
`
`10:45, 4:23-45, 3:54-61, 12:17-46, Figs. 1, 8A-8B (steps 814, 816, 828, 818, 828).
`
`See also Olsen applied to Elements 7(c) and 13(c). Olsen similarly discloses that
`
`specific users can be assigned to a license certificate in order to allow access to a
`
`particular application. Id. at 4:47-52 (“[T]he license certificate object facilitates
`
`adding assignment information to license certificates to assign or delete particular
`
`users to an application for access. In addition, ownership of the license may be
`
`transferred to another user ….”), 13:52-55.
`
`[1(d)] providing an unavailability indication to the client responsive to the
`selection if the license availability indicates that a license is not available for
`the user or an availability indication if the licensed availability indicates that a
`license is available for the user.
`
`Olsen teaches providing an error message (i.e., unavailability indication) to a
`
`client in response to the user’s request for access to a particular application (i.e.,
`
`responsive to the selection) if, for example, the license certificate security
`
`assignment does not include the user and/or or there are no available license units
`
`(i.e., if the license availability indicates that a license is not available for the user).
`
`
`
` 18
`
`

`

`Olsen teaches providing a license, along with the application and license handle
`
`(i.e., availability indication) if, for example, the license certificate security
`
`assignment includes the user and there are available license units (i.e., if the
`
`licensed availability indicates that a license is available for the user).
`
`“If all of the available LSPs 110 have been searched (step 822) and the
`appropriate license units cannot be located, LSP 110 returns an error
`message to client 106 (step 824). If the appropriate buffers are available
`among the various LSPs, the license certificate objects consume the detected
`license units. To consume the units, each license certificate object checks the
`license information for any existing assignments. If an assignment exists on
`the license certificate, it performs a security equivalency check to determine
`whether the requesting client 106 is among those assigned to the license
`certificate (step 828). If no match is found, the license certificate object
`returns an error to the requesting client (step 830).
`
`If a match is found, the license certificate object consumes the license units
`by updating the buffer with the user information, license handle, and how
`many units are to be consumed (step 832). The various buffers in license
`certificate database 112 are modified to indicate that various attributes have
`been incorporated into a license certificate object. For example, if only a
`limited number of users may use an application simultaneously, then the
`value in the buffer corresponding to the number of units available is
`decremented by the number of units accorded to the license certificate object.
`All such modification of the buffers are performed according to the policy
`attributes associated with the license certificate.
`
`
`
` 19
`
`

`

`The license certificate object acquisition process continues to request units
`from buffers until all of the required buffers are obtained or the necessary
`buffers to proceed cannot be found. If insufficient license units were located
`(step 834), a detailed error code indicating the grounds for denial of the
`request is returned to client 106 and stored in the transactional database
`(step 836). If the appropriate buffers are located, however, the license
`certificate object suitably grants the license base