[go: up one dir, main page]

WO2000011575A1 - Systeme, procede et programme informatiques servant a gerer et a analyser des transactions relatives a la propriete intellectuelle - Google Patents

Systeme, procede et programme informatiques servant a gerer et a analyser des transactions relatives a la propriete intellectuelle Download PDF

Info

Publication number
WO2000011575A1
WO2000011575A1 PCT/US1999/019050 US9919050W WO0011575A1 WO 2000011575 A1 WO2000011575 A1 WO 2000011575A1 US 9919050 W US9919050 W US 9919050W WO 0011575 A1 WO0011575 A1 WO 0011575A1
Authority
WO
WIPO (PCT)
Prior art keywords
asset
license
module
use case
payment
Prior art date
Application number
PCT/US1999/019050
Other languages
English (en)
Other versions
WO2000011575A9 (fr
Inventor
Kevin G. Rivette
Irving S. Rappaport
Luke Hohmann
David Puglia
David Goretsky
Adam Jackson
Charles Rabb, Jr.
David W. Smith
Brian Park
Warren Thornthwaite
Jorge A. Navarrete
Robert J. Muller
Harvey Alcabes
Donald Brannon
Matthew Schnitz
Original Assignee
Aurigin Systems, Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Aurigin Systems, Inc. filed Critical Aurigin Systems, Inc.
Priority to AU57808/99A priority Critical patent/AU5780899A/en
Publication of WO2000011575A1 publication Critical patent/WO2000011575A1/fr
Publication of WO2000011575A9 publication Critical patent/WO2000011575A9/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/20—Software design
    • G06F8/24—Object-oriented
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/10—Office automation; Time management
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2216/00—Indexing scheme relating to additional aspects of information retrieval not explicitly covered by G06F16/00 and subgroups
    • G06F2216/11—Patent retrieval

Definitions

  • IP Intellectual Property
  • the present invention is generally related to tools for data processing, and more particularly related to tools for patent-centric and group-oriented data processing.
  • the tools include modules to track and process IP related transactions, such as license agreements.
  • Patents are becoming more and more important to a business's success, especially in today's global economy. Patents can be viewed as a new type of currency in this global economy because they grant the holder with a right to exclude others from making, using, or selling the patented technology. In some industries, product turnover is fairly rapid. However, core technology, product features, and markets change at a much slower rate. Accordingly, even in fast- moving industries, patents which cover core technology are very valuable at protecting a company's research and development investment for an extended period of time. Patents are also valuable as revenue generators. In 1993, for example, the revenue generated from patents by U.S. companies was over $60 billion. Fred Warshofsky, The Patent Wars, John Wiley & Sons, Inc., New York, 1994. These patent revenue dollars are rising each year.
  • Patents are further valuable because they collectively represent a vast technological database. Much of this database is only available as issued patents
  • patents remain one of the most underutilized assets in a company's portfolio. This is due, at least in significant part, to the fact that patent analysis, whether for purposes of licensing, infringement, enforcement, freedom to operate, technical research, product development, etc., is a very difficult, tedious, time consuming, and expensive task, particularly when performed with paper copies of patents.
  • a number of patent searching tools are available, such as the United States Patent and Trademark Office (USPTO) Automated Patent System (APS), and the on-line search services offered by Lexis and Westlaw.
  • Other providers of patent information and patent search tools include Derwent, MicroPatent, Questel, Corporate Intelligence, STN, M/Plenum, The Shadow Patent Office (EDS), LBM, and CAS. These tools are not analysis tools. Instead, they are search tools. These tools enable a user to identify patents that satisfy a specified key word search criteria.
  • these tools provide the user with the ability to possibly find "the needle-in-the-haystack.”
  • these tools have limited, if any, automated functions to aid a user in analyzing the patents, whether the company's own patents or those of competitors, for the purpose of making tactical and strategic business decisions based on the patents.
  • SmartPatents Inc. provides electronic tools for analyzing patents. These tools, collectively called the SmartPatent Workbench, are very useful for analyzing patents.
  • the SmartPatent Workbench a user can view the text and image of a patent, conduct text searches in the patent, copy and paste portions of the patent to other documents, build a case of patents, annotate the case and the patents in the case, import and export patents and cases, etc.
  • the SmartPatent Workbench is commercially available from SPI, and is described in a number of publicly available documents, such as U.S. Patent No. 5,623,679 and U.S. Patent No. 5,623,681.
  • the present invention includes a system, method, and computer program product to track, analyze, and report on information related to intellectual property (IP) transactions, including license and related agreements.
  • IP intellectual property
  • FIG. 1 illustrates the document-centric and patent-centric operation of the present invention
  • FIG. 2 is a block diagram of a system according to a preferred embodiment of the present invention.
  • FIG. 3 is a block diagram of an enterprise server according to a preferred embodiment of the present invention
  • FIG. 4 is a block diagram of the databases of the present invention
  • FIG. 5 is a block diagram of a network client (and potentially a web client) according to an embodiment of the invention.
  • FIG. 6 is a block diagram of the analysis modules which form a part of the enterprise server of FIG. 3;
  • FIG. 7 is a block diagram of a computer useful for implementing components of the invention;
  • FIG. 8 A illustrates the orientation of FIGS. 8B-8M relative to one another;
  • FIGS. 8B-8M illustrates the tables and attributes in the databases of FIG.
  • FIG. 9 represents an example console screen shot
  • FIG. 10 is another example console screen shot
  • FIG. 11 A illustrates a block diagram of a licensing module
  • FIG. 1 IB illustrates a more detailed block diagram of the licensing module according to an embodiment of the invention
  • FIG. 12 illustrates a standalone configuration of the licensing module
  • FIG. 13 illustrates an integrated configuration of the licensing module
  • FIG. 14 illustrates an example screen shot of an object display window generated by a licensing module according to an embodiment of the present invention
  • FIG. 15 illustrates an actor hierarchy according to an embodiment of the licensing module
  • FIG. 16 is a conceptional diagram of databases used by the licensing module according to an embodiment of the present invention.
  • FIG. 17A is a block diagram of the functional modules in the licensing module according to an embodiment of the invention.
  • FIG. 17B is a block diagram of a licensing administration module according to an embodiment of the invention.
  • FIG. 19 is an example screen shot of a log-in window according to an embodiment of the invention.
  • FIG. 22 illustrates an example screen shot of a contact view according to an embodiment of the invention
  • FIG. 30 illustrates an example screen shot of an asset view according to an embodiment of the invention
  • FIG. 32 illustrates the use of pull down menus to create new objects according to an embodiment of the invention
  • FIGS. 33-35 illustrate example screen shots of dialogs for entering new patent assets according to an embodiment of the invention
  • FIGS. 37-40 illustrate example screen shots of dialogs for entering new trademark assets according to an embodiment of the invention
  • FIGS.42-44 illustrate example screen shots of dialogs related to entering new copyright assets
  • FIG. 47 illustrates an example screen shot for entering a new know how asset according to an embodiment of the invention
  • FIGS. 50-57 and 59 illustrate example screen shots of dialogs and windows associated with asset packages
  • FIGS. 64 A, 64B, 65, and 66 illustrate example screen shots of dialogs related to a find asset tool
  • FIG. 67 illustrates the manner in which a pull down menu can be used to invoke a find tool
  • FIGS. 68-72 and 81 illustrate example screen shots related to license agreements according to an embodiment of the invention
  • FIGS. 87 A and 88-90 illustrate example screen shots related to royalty statements according to an embodiment of the invention
  • FIGS.95-99 illustrate example screen shots related to payments according to an embodiment of the invention
  • FIG. 108 illustrates an example screen shot of a reports view according to an embodiment of the invention
  • FIGS. 110A-110C, 111A-111D, 112A-112F, 113, 114A-114B, 115A- 115C, 116, and 117 illustrate example reports generated by the licensing module according to an embodiment of the invention
  • FIGS. 125 A and 125B illustrate a flowchart representing an example operational thread of an embodiment of the invention
  • FIGS. 126-150 illustrate block diagrams of subsystems of the licensing module according to embodiments of the invention.
  • FIGS. 151-163 illustrate additional use case diagrams representing additional functions supported by the present invention.
  • the present invention is directed to a system, components of the system, a method, components of the method, and a computer program product for patent-centric and group-oriented data processing. Such processing includes, but is not limited to, reporting, analyzing, and planning.
  • FIG. 1 is a conceptual representation of the invention.
  • the present invention processes patent information 104, which is herein defined to include (but not limited to) U.S. and non-U.S. patents (text and/or images) and post issuance documents (such as Certificates of Correction), and patent-related information, which includes information about patents (herein called patent bibliographic information). Accordingly, the processing performed by the invention is said to be "patent-centric” or "patent-specific.”
  • the present invention processes any documents, some of which are related to patents, and others which are unrelated to patents. These documents are preferably of interest to a business entity, and include contracts, licenses, leases, notes, commercial papers, other legal and/or financial papers, etc., as well as patents.
  • the present invention also processes other information, preferably business-related information, including (but not limited to) research and development (R&D) information 106, financial information 116, patent licensing information 114, manufacturing information 108, and other relevant business information 110 (which may, for example, include human resources information).
  • R&D research and development
  • financial information 116 financial information
  • patent licensing information 114 patent licensing information
  • manufacturing information 108 manufacturing information
  • other relevant business information 110 which may, for example, include human resources information.
  • non-patent information since it includes documents other than patents and may further include information from operational and non-operational corporate databases.
  • the present invention is adapted to maintain and process massive amounts of documents (several hundred thousand or more). It is often necessary to maintain and process this large number of documents in order to develop strategic, patent-related business plans for the customer. According to the present invention, processing of the patent information 104 can be conducted either with or without consideration of any of the other information 106, 116, 114, 110, 108.
  • a group is a data structure that includes a collection of patents.
  • the patents in a group typically follow a common theme or characteristic (although this is not a mandatory requirement of groups).
  • a first group may include patents that map to a product being manufactured and sold by a company.
  • a second group may include patents that map to a product or product feature being considered for future manufacture and sale by a company.
  • a third group may include patents owned by a corporate entity.
  • a fourth group may include patents each having a particular person named as an inventor.
  • a fifth group may include patents owned by a competitor.
  • a sixth group may include patents related to a research project.
  • a seventh group may include licensed patents.
  • An eighth group may include patents and/or non-patent documents related to a litigation in which the customer is involved or has an interest (such a group is also herein called a case).
  • a ninth group may include patents and other documents arbitrarily selected by a customer.
  • the present invention is capable of automatically processing the patents in a group, or the patents in multiple groups (alternatively, the invention can automatically process a single patent). Accordingly, the present invention is said to support "group-oriented" data processing.
  • processing of the patent information 104 is conducted with consideration of other information 106 , 116, 114, 110, 108, called non-patent information.
  • the process of assigning patents to groups is an example of processing patent information with non-patent information. This is the case, because groups are often created according to non- patent considerations. Accordingly, any subsequent processing of the patents in a group involve, by definition, non-patent considerations.
  • a group may also contain non-patent documents. In fact, a group may contain only non-patent documents. Accordingly, a group is more generally defined as a collection of documents (such as patent documents only, non-patent documents only, or a combination of patent and non-patent documents). The documents in a group typically follow a common theme or characteristic
  • the invention processes document information 104 alone, or in conjunction with other information 106, 116, 114, 110, 108 (which may or may not be related to the documents). Accordingly, the processing performed by the present invention is more generally described as being document-centric and group-oriented.
  • FIG. 2 is a block diagram of a system 202 according to an embodiment of the invention.
  • the system 202 includes a plurality of databases 216 that store patent information and other information, such as R&D (research and development) information, financial information, licensing information, manufacturing information, HR (human resources) information, and any other information that may be pertinent to the analysis of the patent information.
  • R&D search and development
  • financial information such as financial information, licensing information, manufacturing information, HR (human resources) information
  • HR human resources
  • An enterprise server 214 accesses and processes the information in the databases 216.
  • the enterprise server 214 includes modules that are capable of automatically accessing and processing the information in the databases 216 in a patent-centric (or document-centric) and group-oriented manner. These modules are also capable of automatically accessing and processing the information in the databases on a patent by patent basis ("one patent at a time"). Such processing includes, but is not limited to, reporting, analyzing, and planning.
  • the system 202 preferably includes two types of clients, network clients 206 and web clients 204. These clients 204, 206, pursuant to instructions from human operators or users (not shown), interact with the enterprise server 214 to access and process the information in the databases 216.
  • the clients 204, 206 may request that the enterprise server 214 retrieve certain information, or automatically analyze certain information.
  • the enterprise server 214 performs the requested tasks, and sends the results to the requesting clients 204, 206.
  • the clients 204, 206 present these results to their respective operators, and enable the operators to process the results.
  • the components of the present invention shown in FIG. 2 are implemented using well known computers, such as a computer 702 shown in FIG. 7.
  • the computer 702 can be any commercially available and well known computer capable of performing the functions described herein, such as computers available from International Business Machines, Apple, Silicon Graphics Inc., Sun, HP, Dell, Compaq, Digital, Cray, etc.
  • the computer 702 includes one or more processors (also called central processing units, or CPUs), such as a processor 706.
  • the processor 706 is connected to a communication bus 704.
  • the computer 702 also includes a main or primary memory 708, preferably random access memory (RAM).
  • the primary memory 708 has stored therein control logic 710 (computer software), and data 712.
  • the computer 702 also includes one or more secondary storage devices 714.
  • the secondary storage devices 714 include, for example, a hard disk drive 716 and/or a removable storage device or drive 718.
  • 718 represents a floppy disk drive, a magnetic tape drive, a compact disk drive, an optical storage device, tape backup, ZIP drive, JAZZ drive, etc.
  • the removable storage drive 718 interacts with a removable storage unit 720.
  • the removable storage unit 720 includes a computer usable or readable storage medium having stored therein computer software (control logic) and/or data.
  • the removable storage drive 718 reads from and/or writes to the removable storage unit 720 in a well known manner.
  • Removable storage unit 720 also called a program storage device or a computer program product, represents a floppy disk, magnetic tape, compact disk, optical storage disk, ZIP disk, JAZZ disk/tape, or any other computer data storage device.
  • Program storage devices or computer program products also include any device in which computer programs can be stored, such as hard drives.
  • the present invention is directed to computer program products or program storage devices having software that enables the computer
  • Computer programs are stored in main memory 708 and/or the secondary storage devices 714. Such computer programs, when executed, enable the computer 702 to perform the functions of the present invention as discussed herein. In particular, the computer programs, when executed, enable the processor 706 to perform the functions of the present invention. Accordingly, such computer programs represent controllers of the computer 702.
  • the modules of the invention discussed herein, such as the grouping module 312, the analysis modules 316, etc., preferably represent software executing in the computer 702.
  • the computer 702 also includes a display unit 722, such as a computer monitor, and one or more input devices 724, such as a keyboard, a mouse, other pointing devices (such as a light pen and trackball), etc.
  • the computer 702 further includes a communication or network interface
  • the network interface 726 enables the computer 702 to communicate over communication networks, such as networks 208 and 212, which preferably use the well known HTTP communication protocol.
  • FIG. 4 illustrates the databases 216.
  • the databases 216 store document information (that includes patent information) and information pertinent to the analysis of the document information.
  • FIG. 4 illustrates a particular embodiment of the databases 216, and also illustrates a particular embodiment of the types of tables that the databases 216 contain, and the attributes in the tables. It should be understood, however, that the invention is not limited to the particular database embodiment of FIG. 4. Instead, the invention is adapted and intended to cover other database structures and organizations that are capable of storing document information and information pertinent to the analysis of the document information.
  • the particular information that is stored in the databases is implementation dependent and varies based on a number of factors, including the type of analysis that is desired, the specific needs of the customer, the type and content of the information that the customer maintains, etc.
  • databases 216 such as the BOM databases 426, the inventor databases 428, and corporate entity databases 430, the financial databases 438, the person databases 432, and the employee databases 434, are initially loaded using information provided by the customer.
  • information includes R&D (research and development) information, financial information, licensing information, manufacturing information, HR (human resources) information, and any other information that may be pertinent to the analysis of the customer's patents and other relevant documents.
  • R&D search and development
  • financial information financial information
  • licensing information licensing information
  • manufacturing information manufacturing information
  • HR human resources information
  • any other information that may be pertinent to the analysis of the customer's patents and other relevant documents.
  • these databases 216 are updated as necessary to reflect changes in the customer's information.
  • Other information such as information for the patent bibliographic databases 404 and the patent database 414, may be loaded using information provided by a third party provider, such as a third party provider that specializes in the provision of patent information in electronic form.
  • the patent bibliographic databases 404 may be periodically updated through a subscription service from such third party providers.
  • the patent database 414 may be augmented through as-needed orders to the third party providers. It should be understood that the present invention works equally well with data provided by any party as long as the data's format matches the formats of the patent bibliographic databases 404 and the patent database 414.
  • the document databases 412 preferably include electronic representations of documents of interest to the customer.
  • the document databases 412 represent the customer's repository of documents, and are thus also called the customer's document repository.
  • the "repository” could alternatively represent all documents represented in the databases 216, whether represented in the document databases 412 or the bibliographic databases 402.
  • the patent database 414 includes electronic representations of U.S. and foreign patents of interest to the customer. These patents may be patents owned and/or licensed by the customer, patents owned and/or licensed by competitors of the customer, patents that the customer is considering acquiring, patents that, for whatever reason, the customer is studying, etc.
  • the patent database 414 represents the customer's repository of patents, and is thus also called (in some embodiments) the customer's patent repository.
  • the patent database 414 preferably has stored therein an image file and a text file for each patent represented in the patent database 414, where the image file and the text file are representations of the patent. Details of an embodiment of the image file and the text file are described in U.S. Patent No. 5,623,681 and
  • the document databases 412 also include electronic representations of other documents of interest to the customer, such as depositions, pleadings, and prior art references These documents are respectively stored in a deposition database 418, a pleadings database 416 (generally, pleadings are papers filed with a court), and a prior art database 420 Text and/or image representations of these documents may be stored These documents may be pertinent to a patent litigation that the customer is involved in
  • the documents in the document databases 412 may be text, images, graphics, audio, video, multimedia, and/or any other information representation that can be stored in electronic form
  • document databases 412 of FIG 4 are shown for purposes of illustration, and not limitation As mentioned above, the document databases 412 store electronic representations of documents that are of interest to the customer Accordingly, the types of document databases 412 and the contents of the document databases 412 are, by definition, customer and implementation specific
  • the document bibliographic databases 402 store information about documents (as opposed to the documents themselves) More particularly, the document bibliographic databases 402 store bibliographic information about documents
  • the patent bibliographic databases 404 store bibliographic data about U S and non-U S patents Such patent bibliographic data includes, but is not limited to, the information on the front page of patents, such as the patent number, the issue date, the inventors, the title, the assignee, the serial number, the filing date, the U.S. and international classifications, the fields of search, the references cited, the primary examiner, the assistant examiner, the attorney, the agent, the law firm, priority information, related application information, the number of claims, the number of drawing pages, the patent term, the expiration date, etc.
  • the patent bibliographic databases 404 can also include one or more user defined fields that can store large amounts of data, such as 32 Kbytes or more of data.
  • the patent bibliographic databases 404 store bibliographic information on all U.S. patents. In other embodiments of the invention, the patent bibliographic databases 404 store patent bibliographic information on a subset of all U.S. patents, such as all U.S. patents that are available in electronic form from the U.S. Patent Office, or all U.S. patents that issued after a certain date.
  • the document bibliographic databases 402 include store bibliographic information on other types of documents that are of interest to the customer. For example, if the customer is interested in depositions, pleadings, or prior art references, then the document bibliographic databases 402 would store bibliographic information on depositions, pleadings, or prior art references in deposition bibliographic databases 406, pleadings bibliographic databases 408, and prior art bibliographic databases 410, respectively.
  • the present invention supports annotation of the documents in the document databases 412. More particularly, the present invention allows users to create and link annotations (also called notes) to any portions of the documents in the document databases 412.
  • annotations can include text, graphics, images, video, audio, and/or any other information representation that can be stored in electronic form.
  • the present invention also allows various information to be stored with annotations, such as the date of creation, the creator, the date of modification, a note title and/or subject, access rights, etc.
  • Embodiments of the notes databases 440 are described in U.S. Patent No. 5,623,679 and U.S. Patent No. 5,623,681.
  • a group is a data structure that includes any number of documents that typically follow a common theme or characteristic (although this is not a mandatory requirement of groups). More particularly, a group is a data structure that includes any number of patents that typically follow a common theme or characteristic (although, again, this is not a mandatory requirement of groups).
  • predefined groups also called system defined groups
  • user-defined groups also called arbitrary groups
  • Patents (and/or documents) in predefined groups follow a predefined theme or characteristic.
  • Database tables, fields, and attributes of a predefined group are specific to the predefined theme/characteristic of the predefined group. Accordingly, different predefined groups have different database tables, different database fields, and different database attributes.
  • Information on predefined groups is stored in the predefined or system defined group databases 422.
  • Patents (and/or documents) in user-defined groups may or may not follow a common theme or characteristic. Any theme or characteristic that they do follow is defined by the user. Accordingly, user-defined groups are also called arbitrary groups.
  • All user-defined groups have the same, generic database tables, fields, and attributes. However, users may elect to use these database tables, fields and attributes differently for different user-defined groups. Information on user-defined groups is stored in the user-defined group databases 424.
  • the enterprise server 214 is preferably implemented as one or more computers (such as the computer 702 shown in FIG. 7) each having at least 128 MBytes of main memory 708 and running Microsoft Windows NT.
  • the enterprise server 214 could, alternatively, be implemented using other memory configurations, and other operating systems, such as (but not limited to) UNIX, Windows 95, MS-DOS, the Apple Operating System, etc. Accordingly, the specific hardware and software implementations discussed herein are provided for purposes of illustration, not limitation (this applies to all specific hardware and software implementations discussed herein, both for the enterprise server 214 and for other components of the invention).
  • the invention can utilize any hardware, software, and operating system capable of performing the functions described herein.
  • the document storage and retrieval module 308 in the enterprise server 214 stores and retrieves documents from the document databases 412.
  • the notes module 314 manages and interacts with the notes databases 440.
  • the client notes module 514 enables a user to view and manipulate notes.
  • the searching module 310 in the enterprise server 214 interacts with a search engine 324 to conduct searches through the data in the databases 216 pursuant to search requests from the clients 204, 206.
  • the grouping module 312 in the enterprise server 214 manages and interacts with the group databases 421.
  • the analysis modules 316 are shown in FIG. 6. These analysis modules 316, which are also called methodology modules 316, automatically interact and process data contained in the databases 216 pursuant to user commands.
  • FIGS. 8B-8M The database structures of the document bibliographic databases 402, the group databases 421, the person databases 432, the employee databases 434, the security databases 436, the financial databases 438, and the methodology support databases 442 are shown in FIGS. 8B-8M. These figures also depict the interaction and connection between these databases.
  • FIG. 8 A illustrates the preferred orientation of FIGS. 8B-8M with respect to one another.
  • the tables and attributes shown in FIGS. 8B- 8M only represent one embodiment of the present invention.
  • the data in the databases 216 could be stored using other combinations of tables and attributes. Such other combinations of tables and attributes will be apparent to persons skilled in the relevant arts based on the discussion contained herein. Accordingly, the tables and attributes are shown in FIGS. 8B-8M only for purposes of illustration, and not limitation.
  • the financial modules 610 in the enterprise server 214 perform patent- centric and group-oriented processing of the data in the financial databases 438.
  • Examples of the functions performed by the financial modules 610 include determining the research and design (R&D) expenditures on a product or product line basis, determining the R&D expenditures per inventor or per employee on a product or product line basis, determining net licensing revenue on a product or product line basis, determining the number of patents issued on a product or product line basis, determining patent maintenance fees on a product or product line basis, determining market share on a product or product line basis, determining the tax rate on a product or product line basis, determining marketing costs on a product or product line basis, determining selling costs on a product or product line basis, determining the number of outstanding shares (P/E) on a product or product line basis, determining revenue on a product or product line basis, determining cumulative product revenue on a product or product line basis, etc.
  • the financial modules 610 can also perform the above processing on a geographical region basis, or on a time basis.
  • FIG. 9 illustrates a console according to an embodiment of the invention.
  • the console 902 includes a first window or pane 904, a second window or pane
  • the first pane 904 is also called the group pane 904
  • the second pane 906 is also called the document pane 906
  • the third pane 908 is also called the notes pane 908.
  • a group hierarchy is depicted in the group pane 904.
  • the top level or root group in the group hierarchy is called the repository group 910.
  • the child groups of the repository group 910 are not shown in FIG. 9 (i.e., the operator has not expanded the repository group 910 in the group pane 904).
  • the child groups of the repository group 910 are shown in FIG. 133 (i.e., the operator has expanded the repository group 910 in the group pane 904 in the example of FIG. 10).
  • the document pane 906 includes a list of patents and other documents which are contained within a group selected from the group hierarchy depicted in the group pane 904.
  • the patents and documents are listed in a tabular or "spreadsheet" format.
  • the list of patents and documents in the document pane 906 includes both the patent numbers and patent Bibliographical information for the patents, and bibliographic information for the non-patent documents.
  • Such patent bibliographic information displayed in the document pane 906 includes the title, abstract, inventor, class, issue date, and user-defined keywords. All additional patent bibliographic information can be viewed in the document pane 906 by utilizing the horizontal scroll bar 920 to sideways scroll in the document pane 906.
  • Other embodiments of the invention allow the user to select an arbitrary number of bibliographic fields to view. In example of FIG. 9, no patents are listed in the document pane 906 because a group has not been selected in the group hierarchy depicted in the group pane 904.
  • the notes pane 908 displays a list of the notes associated with either a group selected in the group pane 904, or a patent or document selected in the document pane 906.
  • the list of notes in the notes pane 908 is presented in a tabular or "spreadsheet" format.
  • the list of notes in the notes pane 908 includes information that identifies the type of the note (that is, either a patent/document note or a group note), and the title of the note. All other bibliographic or other information relating to notes can be viewed by manipulating the horizontal scroll bar 922 in order to sideways scroll in the notes pane 908.
  • an embodiment of the invention includes a licensing module 1102 (also herein called the licensing system 1102).
  • the licensing module 1102 is also referred to herein as the SmartPatents PrismTM system.
  • the licensing module 1102 provides the tools a licensor needs to manage its licensing effectively through tracking a variety of objects, including but not limited to out-licenses (i.e., licenses where the corporate entity is the licensor), in-licenses
  • licenses where the corporate entity is the licensee
  • licensing parties i.e., any parties involved with a license agreement, such as the licensee(s), the licensor(s), license agents, license organizations, attorneys, etc.
  • royalty statements i.e., royalty payments, etc.
  • Customers also use the licensing system 1102 to better understand how they are making strategic use of their IP assets and to audit the licensees' contribution to the value of those assets.
  • the licensing module 1102 is a standalone system, existing and operating independently of the enterprise server 214 and the enterprise databases 216. In this standalone configuration 1201, the licensing module 1102 does not access data in enterprise/IP AM database 216. Instead, the licensing module 1102 utilizes data in its own databases, i.e., a licensing database 1204 and a core database 1208, among potentially others. These databases are described in detail below. (The invention is not limited to the arrangement of data described herein. In other embodiments, the data and attributes described herein are stored in combinations of databases and tables other than that described herein.)
  • the licensing module 1 102 interacts with the enterprise server 214 and/or the enterprise databases 216, such that users of the licensing module 1102 may access and utilize groups and/or IP assets, as well as other information, stored in the enterprise databases 216, and/or may interact with the enterprise server 214 to further manage groups of IP assets and/or other objects that are being tracked through the licensing module 1102.
  • the enterprise server 214 is herein also sometimes referred to as the Intellectual Property Asset ManagerTM (JPAMTM) server 214.
  • the database architecture associated with the licensing module 1102 includes a number of databases.
  • the standalone embodiment of the licensing module 1102 includes a Licensing database 1204 and a Core database 1208.
  • the IPAM-integrated embodiment of the licensing module 1102 includes the Licensing database 1204.
  • the Core database 1208 is substantially or completely replaced with the enterprise database 216 (also called the IP AM database 216).
  • the Core database 1208 contains standalone versions of all of or at least a subset of the tables included in the IP AM Server database 216. Accordingly, when the IP AM database 216 is available, there is little or no need for the core database 1208.
  • the licensing module 1102 is implemented as a two- tier client/server model.
  • the licensing module 1 102 is implemented as a three-tier model using standard middleware technology such as CORB A or COM along with technologies compatible with them, including the appropriate security manager for the application server middleware layer.
  • the architecture preferably provides a thin-client C++ component, a secure application domain server, and a secure database server (such as a SQL Server), linking the latter two components with ODBC for maximal portability.
  • the user interface and object model are tightly integrated and use well known component technologies such as ActiveX and DAO.
  • security relies on defining SQL Server database users with passwords and appropriate privileges on the database objects.
  • IP business related information such as but not limited to existing license agreements, new license agreements, and/or related objects, such as but not limited to assets, asset packages, contacts, compensation terms, and so on.
  • the Data Entry Clerk enters assets, and the License Administrator creates asset packages to package assets for licensing.
  • the Data Entry Clerk enters contacts by entering organizations, people, and contact methods.
  • the Data Entry Clerk enters the license information.
  • the License Administrator takes over to modify the license agreement with more complex data that requires an understanding of licensing.
  • the License Administrator begins querying the system interactively in response to questions and issues that arise. He or she will also start generating reports. At some point, an auditor or other interested party will also query and generate reports. The License Administrator then may need to do some maintenance on the agreements, accompanied by occasional maintenance by the IP AM Administrator on objects that require Administrator privileges to remove.
  • the licensing module 1102 enables users to manage, track, interact with, process, analyze, etc., intellectual property (IP) related transactions.
  • IP related transactions include the licensing of IP assets, and the management, tracking, interaction with, processing, analysis, etc., of such licensing activities using license agreements, asset packages, royalty statements, payments, etc.
  • the invention is not limited to this embodiment. Instead, the invention is intended and adapted to cover the management, tracking, interaction with, processing, analysis, etc., of IP related transactions using any object, vehicles, data, etc., in accordance with the scope and spirit of the functions described herein.
  • the Licensing module 1102 includes a number of features, including but not limited to the following:
  • ° Market opportunity tracking Tracking of sales opportunities related to contacts, including inquiries, targeted potential customers, and infringement tracking.
  • ° Marketing Communications and Sales support Support for customer inquiries, IP marketing brochure querying, and e-commerce sales support.
  • ° Electronic Data Interfacing support for the ability to transfer royalty statements and payments from licensee to licensor automatically through the Internet or other communications media to improve compliance, simplify auditing, and reduce data entry requirements.
  • ° Licensing In Extensive support for the licensee, including royalty statement generation, payment due flagging, and sublicense tracking.
  • ° Compliance workflow Support for the contract administrator in monitoring the compliance of agreement parties to the terms and conditions of the license agreement, such as generating royalty invoices, checking revenue numbers, and detailed representation of contract clauses and their compliance requirements
  • Sublicense tracking The ability to track sublicensing of a license agreement for better royalty tracking and control and contract compliance.
  • ° Contract development workflow Support for user-defined templates for license agreements and generation of standard agreements with designated clauses.
  • ° International licensing support support for various issues that arise with international licenses, including support for offset licensing ("counter trade” or "industrial participation” licensing) and the various registration requirements for copyrights, trademarks, and patents in foreign countries and the import/export requirements of foreign governments that impact royalty and fee payments.
  • Custom report integration the ability to integrate custom reports into the Reports View and run them along with standard reports. This includes integration of a complete report writer into the Licensing module 1102.
  • ° Administrative audit trails support for object version auditing through recording the user and timestamp for each change to the persistent data.
  • ° Help Desk support Extensive support for internal customers of the system getting answers to basic questions through query facilities in the Licensing module 1102, ranging from a simple frequently-asked-question style to the ability to query information about licenses, royalty statements, and payments.
  • the licensing module 1102 is described in greater detail in the following sections.
  • the licensing module 1102 involves a number of user roles, including but not limited to the following.
  • the invention is not limited to these functions being performed by the people specified below. In other embodiments, other people in other user roles can perform the following functions.
  • the Data Entry Clerk a user who enters basic data about contacts, licenses, royalty statements, and license payments. Generally, a Data Entry Clerk does not require much knowledge about licensing or intellectual property.
  • the License Administrator a user who enters more complex information about licenses, royalty statements, and payments and who works with executives, corporate counsels, licensees, and others to provide information about the licenses and revenue in the IP AM system 1 102.
  • a License Administrator requires extensive knowledge about licensing and licensed intellectual property.
  • the Auditor a user who generates summary and detail reports about the licenses and their associated revenue and who queries information interactively to investigate specific issues.
  • an Auditor requires extensive knowledge about licensing and the details of accounting for license revenue, but does not require write access to the system.
  • the System Administrator a user who handles security management, data entry of supporting database information, and cleanup of the database on demand from others.
  • the Database Administrator a user who sets up and controls the physical layout of the database that the licensing module 1102 uses.
  • FIG. 15 illustrates an object-oriented view of a preferred actor hierarchy 1502 for the licensing system 1102.
  • all actors inherit the base capabilities of a generic user 1504, who may be a user of the licensing system 1102. This user, for example, could have the authority to view data, conduct searches, and run reports.
  • Other actors such as the system administrator 1506, the data entry clerk 1508, the auditor 1512, and the database administrator 1516, have capabilities above and beyond that of the user 1504. These additional capabilities are elaborated above, and further indicated below.
  • a super user, the licensing administrator 1518 preferably has complete access to the licensing system 1102, and thus is shown in FIG. 15 as inheriting all the capabilities of all the other actors.
  • Architecture preferably has complete access to the licensing system 1102, and thus is shown in FIG. 15 as inheriting all the capabilities of all the other actors.
  • FIG. 1 IB is a block diagram of the licensing system 1102 according to an embodiment of the invention.
  • Licensing module 1102 There are three general functions of the Licensing module 1102: data entry, data exploration, and reports. Underneath the user interface, there is an object model that implements all the different kinds of licensing objects that Licensing module 1102 needs to support data entry, to provide exploration of the database, and to permit generation of effective reports. Licensing module 1102 preferably connects to a SQL Server database server 1140 through ODBC 1 138 to provide persistent storage of its data and to support third-party report definitions.
  • the user interface preferably includes the following components.
  • the licensing system user interface module 1101 is the primary user interface for the licensing related functions of the licensing system 1102 described herein.
  • the licensing system user interface module 1101 interacts with users via the windows and dialogs described herein.
  • the licensing system user interface module 1101 is written in Visual C++ and MFC (Microsoft Foundation classes, a well known class library for Visual C++), although the invention is not limited to this implementation.
  • the licensing system administrator user interface module 1104 is the user interface to the licensing related administrative functions described herein.
  • the licensing system administrator user interface 1104 is preferably written in Visual C++ and MFC, although the invention is not limited to this implementation.
  • operation of the licensing module 1102 is based on license agreements.
  • the invention is not limited to this embodiment.
  • the licensing module 1102 is based on other IP related transactions, such as assignment agreements, technology transfer agreements, security interests, or any other agreement involving a transaction that includes or relates to an IP asset.
  • license agreements are completely nonstandard in text format, but customers need to track specific, standard information about the agreement: its terms, its duration, its parties, the payments and statements customers receive, etc. They need to explore how their IP assets are generating revenue. They need to be able to license IP assets including patents, trademarks, copyrights, know how, trade secrets, other licenses, etc. Customers need to package multiple assets for licensing through a single license. They need to report on different aspects of their license portfolio. They need to search the document text to identify agreements that they can use as templates for further agreements.
  • the Licensing module 1102 enables users to enter structured data about license agreements, royalty statements, payments (this information is preferably stored in the licensing database 1204).
  • the licensing module 1102 also enables users to enter data about companies and people to which IP assets can be licensed (this information is preferably stored in the licensing database 1204).
  • the licensing module 1102 also enables users to enter IP assets (patents and other types) (this information is preferably stored in the licensing database 1204).
  • This part of the licensing system 1102 can link to the IP AM Server 214 for access to the IP assets and groups it supports.
  • the licensing module 1102 also adds to those IP assets as necessary to round out the range of asset types that customers wish to license: trademarks, copyrights, and trade secrets as well as patents.
  • information on non-patent assets are stored in the licensing database 1204 or the core database 1208.
  • Information on patent assets are stored in the IP AM database 216 when working in the IP AM integrated mode (FIG. 13), and stored in the licensing database 1204 or the core database 1208 when working in the standalone mode (FIG. 12).
  • the Licensing module 1102 also provides asset packaging options beyond lists of assets, including search packages based on IP AM search groups and descriptive asset packages that define asset groups with text rather than enumerating assets.
  • Licensing reports are an important feature of the Licensing module 1102. Customers use reports generated by the licensing module 1 102 to track the revenue due from licenses, to compare that expected revenue to the actual revenue received, and to evaluate the success of license management in their business units. The invention also supports other reports.
  • the report generation module 1106 is responsible for generating the reports requested by users.
  • the report generation module 1106 generates reports using the data in the licensing related databases, including printing the contents of each major object in the system (Print License, Print Asset, and so on).
  • the report generation module 1 106 connects to the databases through ODBC 1138 or through the Microsoft SQL Server driver, for example.
  • the report generation module 1106 can be implemented using a commercial report generation product, such as Crystal Reports, although the invention is not limited to that embodiment.
  • a report generator interface 1132 interacts with the report generator 1106 to cause the report generator 1106 to generate reports per user instructions.
  • the generator interface 1132 may interact with the report generator 1106 in a manner consistent with the API
  • a strategic use of the licensing system 1 102 involves ad-hoc query functions in combination with reports to identify IP assets that are underperforming or outperforming and to cross-reference between license agreements, licensees, royalty terms, royalty statements, and royalty payments.
  • the ad-hoc query facility uses the same user interface that provides data entry facilities in an easy-to-use query-by-example format.
  • the ad-hoc query facilities also support licensing personnel and auditors in interactive tactical tracking down of issues such as payments due, payments not received, royalty statement details, and errors in data entry.
  • the object model of the Licensing module 1102 represents the transient aspect of the persistent data in the database server.
  • the subsystems of the object model provide interfaces to the various licensing-related objects and higher-level objects that aggregate them for use in the Licensing module 1102.
  • the object model supports a number of subsystems and/or object/data types, including but not limited to the following:
  • ° Entity 1112 The people and corporate entities that make up the licensors, licensees, and other parties to the license agreement.
  • ° Contact The contact-related information for entities.
  • ° Agreement 1114 The licensing agreement, including basic royalty terms and advanced royalty structures.
  • IP assets and their groupings including enumerated groups of license agreements , groups based on a search condition from the IP AM
  • ° Payment 1122 The payments received from entities related to licenses and their links to the general ledger.
  • the licensing system domain 1108 is an object layer called a licensing system domain 1108 that represents a series of subsystems (generally indicated as 1148 in FIG. 1 IB) that contain objects that the licensing system 1102 requires to provide the functionality described herein.
  • each subsystem design minimizes the connections to other subsystems from its internal objects with the objective of maximal reusability as components.
  • Each subsystem provides a complete interface to the subsystem and its component objects.
  • Each subsystem is preferably a separate DLL (dynamic link library) and is preferably contained within a separate C++ namespace.
  • Each subsystem exports a set of Transaction subclasses, where a transaction is a Database subsystem component that provides support for database transactions.
  • Each transaction subclass represents a transaction use case.
  • Some transaction classes provide methods for generating objects either as new objects or as objects queried from the database. Others provide the ability to update and delete objects from the database.
  • Each use case is a single transaction through the system, and each must execute entirely within a single thread to ensure thread safety.
  • the use cases supported by an embodiment of the invention are described in sections below.
  • the user interface accesses the transaction subclasses as the primary interfaces. Transactions correspond to the work the user does with those objects (entering new assets, adding payments to a license, and so on).
  • Block diagrams of the subsystems are illustrated in FIGS. 126-150. Details on these subsystems will become apparent from the following discussion of use cases. It is noted that allocation of functions to the subsystems 1148 may vary according to the implementation. Accordingly, the subsystems shown in FIG. 1 IB should be considered only an example.
  • the data access module 1110 provides an interface between system databases 1608 and the modules of the licensing system 1102.
  • the data access module 1110 includes the Microsoft Active Data Objects COM component (preferably version 1.5) that provides a SQL interface for accessing various data sources. In this case, it connects to ODBC 1138.
  • the database architecture preferably includes a Database Server 1 140
  • the databases 1608 in the database architecture each preferably includes a number of databases, each containing a well-defined and reusable set of data components. (It is noted that the invention is not limited to this arrangement of data. In other embodiments, the data described herein is stored in database arrangements other than that described below.)
  • the Licensing database 1204 contains the Role, Agreement,
  • the licensing database 1204 contains tables that provide information about licensing-related objects
  • the Licensing database 1204 also contains the standalone asset data.
  • the Licensing Database 1204 further includes tables supporting time periods (start date/end date type relationships).
  • the licensing database 1204 also contains the Entity and Contact data, i.e., data supporting people, organizations, and contact information for them.
  • the Licensing database 1204 provides a series of views for tables in all the other databases.
  • the domain and the report definitions access the Licensing database 1204, using the views to access data in the other databases.
  • This provides a single, unified database interface for the higher level layers in the licensing system 1102.
  • Views in the Licensing database 1204 are preferably integrated when necessary to provide easier access to complexly related tables. The objective in dividing the tables between several databases is to separate the data for reuse in other applications.
  • the Core database 1208 which contains Group data (that is, information on groups and the assets in each of the groups) and patent asset data
  • the Core database 1208 contains exactly the same or, alternatively, substantially the same tables that are in the IP AM database 216 (optionally, any databases in the IP AM database 216 that are not accessed by the licensing system 1102 are not included in the core database 1208).
  • the standalone version of Licensing module 1102 has a stand-in version of the IP AM database 216 (i.e., the Core database 1208) that, in an embodiment, contains only some of the tables in that database that the module uses (for example, group, document, and a few miscellaneous tables).
  • the patent tables in the IP AM Server database 216 also replaces the patent tables (but not non-patent asset tables) in the licensing database 1204 or the core database 1208 for the integrated version of the Licensing module 1102 (FIG. 12).
  • FIG. 16 illustrates a conceptual, object oriented view of the databases 1608.
  • the licensing database 1204, the core database 1208, and the IP AM database 216 inherit all the abilities of a generic database 1604.
  • Licensing Module As a Standalone Module or Integrated with IPAM (IPAM Integrated)
  • the Licensing module 1102 integrates with the IPAM Server 214 through the IPAM database 216, which it accesses directly.
  • the standalone version of the Licensing module 1102 replaces the IPAM database 216 with a Core database 1208 that emulates the IPAM tables 216 that the Licensing module 1102 uses, including the Group-related tables, the
  • the Licensing module 1102 has all the patent and
  • the Licensing module 1102 integrates with the IPAM security system through the IPAM security broker, a library that is part of the IPAM server technology. Object Display Window of the User Interface of the Licensing module
  • FIG. 14 illustrates an object display window 1402 of the user interface of the Licensing module 1102.
  • the object display window 1402 includes a number of elements: ° Menus: At the top of the object display window 1402 are a variety of pull-down menus 1406. These menus 1406 allow easy access to all of the transactions you can accomplish with the Licensing module 1102
  • a tool bar 1404 Under the pull-down menus 1406 is a tool bar 1404, which presents a line of often-used tools, such as New, Save, Print, and Find.
  • c Licensing Functions Tool B ar Along the side of the obj ect display window 1402 is a licensing functions tool bar 1408 that include icons providing access to the major objects in the Licensing module 1102. These icons include a license agreements icon 1412, a contacts icon 1414, an asset packages icon 1416, a royalty statements icon 1418, a payments icon 1420, a reports icon 1422, and a recycle bin icon 1424. Clicking on one of these icons changes the content of the content view area 1426 so as to display the indicated kind of objects and the various components that make them up.
  • the content view area 1426 is the main area of the object display window 1402.
  • the content view area 1426 contains one or more controls for managing the objects that make up Licensing module 1102.
  • panes include spreadsheet views, and one or more "explorer” or hierarchical views for organizational structure.
  • a spreadsheet view lets you configure the columns to display and sorts on a column when you click on the header.
  • ° Status Bar A status bar 1410 appears at the bottom of the object display window 1402. The status bar 1410 displays application status, short help messages, keyboard status (CAPS LOCK, NUM, etc.), etc.
  • Recycle Bin 1424 If you remove one of the maj or obj ects (entity, asset, asset package, license, royalty statement, payment, currency, etc ), the object gets recorded in the Recycle Bin 1424 You can either restore individual objects m the Recycle Bin view, or you can empty the recycle bin 1424 to make the changes permanent An object in the recycle bin 1424 is preferably not visible anywhere else in the application
  • Dialogs There are various dialogs that pop up (not shown in the example of FIG 14), usually as a result of clicking on a tool button or double-clicking on an object in a spreadsheet, the dialogs accomplish data entry, data modification, searching, etc
  • these functions are implemented by one or more computers operating according to control logic, or software Such software is pieferably written in an object oriented manner Accordingly, the licensing module 1 102 can be said to be an object oriented system
  • Use cases are sometimes used to describe the manner in which an object oriented system works Generally, a use case describes a transaction processed in an object oriented system
  • FIG 17 A An embodiment of the licensing system 1102 is shown in FIG 17 A Each of the ovals shown in FIG 17 A corresponds to a logical functional module of the licensing system 1102 Generally, these functional modules correspond to the use cases that are described below The relationships between the functional modules are indicated in FIG 17A
  • the invention also preferably includes a licensing administration module 1701 (FIG 17B)
  • the licensing administration module 1701 performs administrative tasks associated with the licensing system 1102
  • the licensing administration module 1701 is preferably accessible only by administrators
  • a functional module may "use” another functional module
  • a functional module may call or invoke the services of another functional module
  • a functional module may "extend" another functional module
  • a functional module may extend the capabilities of another functional modules
  • not all relationships between modules are shown in the figures The relationships between functional modules are further descnbed in the following sections
  • the login use case 1802 is diagramed in FIG. 18.
  • the User enters his or her user name and password and any connection string required by the ODBC data source in a login dialog 1902 shown in FIG. 19.
  • the licensing module 1102 logs the user into the server preferably through the
  • the display help use case 2002 is diagramed in FIG. 20.
  • the User requests help in a specific context or requests display of the help contents, index, or query preferably using a standard help system, such as the Microsoft Windows help system.
  • the display help module 1704 displays the appropriate help screen by accessing, retrieving, and displaying pertinent information from a help file 2004.
  • the print object use case is diagramed in FIG. 21.
  • the Auditor or License Administrator selects an object and prints the object in a standard print format to a system printer using the print object module 1706.
  • the operation of the print object module 1706 is further detailed below:
  • Step 1 The Auditor or License Administrator (the Actor) starts the readonly transaction by selecting an object (license agreement, asset package, entity, royalty statement, or payment), and then selects the Print command.
  • ⁇ Object> is one of the five basic objects from step 1.
  • Step 3 The Actor sets the printing options, including any printer setup commands, then issues the instruction to print, ending the transaction.
  • Step 4 The print object module 1706 prints the object. If the Actor in step 1 selects a License Agreement, the Print License use case extends the print object module 1706.
  • the Print Asset Package module 1710 use case extends the print object module 1706.
  • the Print Entity module 1708 extends the print object module 1706.
  • the Print Statement module 1714 use case extends the print object module 1706.
  • the Print Payment module 1716 extends the print object module 1706.
  • a Contact is an organization or person (general term “entity”, which also encompasses users and user groups in the security system). People play roles in organizations, and both people and organizations have contact methods (telephone, mail address, and email).
  • a Contact View 2202 is displayed by selecting the contacts icon 1414 (FIG.
  • the contact view 2202 contains two panes, an explorer view (organization pane) 2204 of organizations and a list of people (people pane) 2206. It is possible to expand and contract the organization hierarchy in a well known manner. When you select an organization, the people in that organization appear in a people list pane 2206 in a tabular spreadsheet format..
  • Double-clicking on an organization in the explorer view 2204 displays the data modification dialog for organizations. Double-clicking on a person in the people list pane 2206 displays the data modification dialog for people. You can double-click on an empty record or click the New button to create a new organization or person.
  • the Licensing System Administrator creates, modifies, and/or removes roles from the Licensing Database 1204.
  • the enter entity use case 2302 is diagramed in FIG. 23.
  • the Data Entry Clerk enters entity information for people and organizations, including organization levels, people's names, and (optionally) contact methods.
  • the Data Entry Clerk may optionally link a person to an organization with a specific role.
  • the enter entity use case 2302 is further described below:
  • Step 1 The Data Entry Clerk begins the transaction.
  • Step 2 The enter entity module 1718 displays the organizations in the organization pane 2204 and people in the people pane 2206 stored in the licensing database 1204 using the Display Entities module 1722.
  • Step 3 The Data Entry Clerk takes any of these actions (for example):
  • Step 3.1 The Data Entry Clerk adds an organization to the list of organizations.
  • Step 3.2 The Data Entry Clerk adds a new person to a list of people for an organization.
  • Step 3.3 The Data Entry Clerk copies an existing person into a new organization.
  • Step 4 The enter entity module 1718 displays a data entry form and creates a new entity unique identifier.
  • Step 5 The Data Entry Clerk enters an optional description for the new organization/person .
  • Step 6 The Data Entry Clerk commits the transaction.
  • Step 7 The licensing system 1102 stores the entered entity information in the licensing database 1204 and confirms the commit to the Data Entry Clerk.
  • the Data Entry Clerk enters the First Name, Middle Name, and/or Last Name.
  • the Data Entry Clerk enters the Name.
  • the Data Entry Clerk enters the date on which the organization came into existence.
  • the Data Entry Clerk chooses an organizational level from a list.
  • the enter contact method use case 2402 is diagramed in FIG. 24. This use case extends or is used by another use case, which supplies the unique identifier of an entity.
  • the Data Entry Clerk enters one or more contact methods for that entity.
  • the enter contact method module 1720 is further described below: Step 1.
  • the using use case passes in an object identifier for an entity with which to associate a contact method.
  • Step 2 The Data Entry Clerk chooses one of three types of contact method: telephone, email, or mail address.
  • Step 3 The enter contact method module 1720 displays an entry form appropriate for the type of contact method selected and generates a unique priority, defaulting it to one more than the last priority entered for methods associated with this entity:
  • WHERE EntityJD :Entity_ID
  • :Entity_ID is the entity object identifier passed into this use case.
  • the Data Entry Clerk can modify the priorities in the Modify Entity use case.
  • Step 4 The Data Entry Clerk optionally enters a Description for the contact method and terminates the use case.
  • the enter contact method module 1720 inserts the contact method into the Licensing Database 1204, linking the entity and contact method. There are a number of extensions with this use case: ° If the contact method is telephone, the Data Entry Clerk enters a country code (default 1), an area code, a telephone number, and (optionally) an extension and whether the phone is a fax line.
  • the Data Entry Clerk enters a domain and an address.
  • the contact method is a mail address
  • the Data Entry Clerk enters a second line of street address and/or a postal code. The Clerk can enter this data in any order.
  • the display entities use case 2502 is diagramed in FIG 25
  • the Enter Entity module 1718 and Modify Entity module 1728 both use the display entities module 1722 to display organizations and people
  • the display entities module 1722 displays a tree of organizations and displays all the people in an organization that the Data Entry Clerk selects
  • the display entities module 1722 is further described below.
  • Step 1 The display entities module 1722 displays a list of top level organizations in alphabetical order from the Licensing database 1204 in the organization pane 2204 of the contact view 2202 The display entities module 1722 then displays in the organization pane 2204, foi each organization, the hierarchy of organizations that have the top-level organization as a parent
  • Step 2 The Data Entry Clerk selects an organization from the organization pane 2204
  • Step 3 The display entities module 1722 displays in the people pane 2206 an alphabetical list of all the people m the organization from the Licensing database 1204, preferably displaying the Entity unique identifier, the entity Name, the entity Descnption, the role Name, and the Start Date and End Date (if any) of the interval du ⁇ ng which the person played the particular role in the organization, all preferably ordered by the last name then first name of the person
  • the user can select to oidei the data in other ways (this is true whenever data is displayed in the present invention) Note that a person may have different roles m the organization, perhaps at different times
  • the display entities module 1722 displays the person only once but supplies a list of roles and time periods for the person with multiple roles
  • the modify entity use case 2602 is diagramed in FIG 26
  • the Data Entry Clerk interacts with the modify entity use case 2602 to modify entity information for people and organizations, including organization levels, people's names, and contact methods.
  • the Data Entry Clerk may optionally modify the links between a person and their roles in organizations.
  • the modify entity module 1728 is further described below:
  • Step 1 The Data Entry Clerk begins the transaction by selecting an appropriate menu option, or pressing an appropriate dialog button.
  • the display entities module 1722 displays a list of top level organizations in alphabetical order from the Licensing database 1204 in the organization pane 2204 of the contact view 2202. The display entities module 1722 then displays, for each organization, the hierarchy of organizations that have the top-level organization as a parent.
  • Step 3 The Data Entry Clerk selects an organization.
  • Step 4 The display entities module 1722 displays an alphabetical list of all the people in the organization from the Licensing database 1204 in the people pane
  • Step 5 The Data Entry Clerk selects an entity (person or organization) for modification.
  • Step 6 The modify entity module 1728 displays a data entry form for the appropriate kind of entity.
  • Step 7 The Data Entry Clerk optionally changes the entity name and/or description in any order.
  • Step 8 The Data Entry Clerk commits the transaction.
  • the modify entity module 1728 updates the Licensing database 1204 with the modified entity information and confirms the commit to the Data Entry
  • the Data Entry Clerk can optionally modify an organizational level from a list.
  • the Data Entry Clerk enters or changes the date on which the organization came into existence.
  • the Data Entry Clerk links the organization to another organization as its parent (the organization the Clerk is entering is the child, the other organization is a parent) .
  • the change modifies any current link.
  • the Data Entry Clerk adds, modifies, or removes a role in an organization using the Link Person to Organizational Role use case, which extends this use case. ° If the Data Entry Clerk wants to enter additional contact information for the entity, the Enter Contact Method use case extends this use case. This repeats as often as necessary.
  • the Modify Contact Method use case extends this use case. This repeats as often as necessary. This use case must query the set of contact methods and let the
  • Data Entry Clerk identify which one to modify.
  • This use case is diagramed in FIG. 27.
  • This use case extends or is used by another use case, which supplies the object identifier for an entity and the priority of the contact method for that entity, which taken together identify the contact method.
  • the Data Entry Clerk can change any of the characteristics of the contact method, which may be a telephone number, a mail address, an email address, etc.
  • the modify contact method module 1726 is discussed further below:
  • Step 1 The modify contact method module 1726 accesses a contact method from the licensing database 1204.
  • the modify contact method module 1726 displays the contact method in a dialog.
  • Step 2 The Data Entry Clerk optionally modifies the Description and details (see Extensions) for the contact method and terminates the use case.
  • Step 3 The modify contact method module 1726 inserts the contact method into the Licensing database 1204, linking the entity and contact method.
  • ° ff the contact method is telephone, the Data Entry Clerk enters a country code (default 1), an area code, a telephone number, and (optionally) an extension and whether the phone is a fax line.
  • ° ff the contact method is email, the Data Entry Clerk enters a domain and an address.
  • the contact method is a mail address
  • the Data Entry Clerk enters a second line of street address and/or a postal code. The Clerk can enter this data in any order.
  • the link person to organization role use case 2802 is diagramed in FIG. 28.
  • the extended use case passes in the object identifier for the person and the organization.
  • the Data Entry Clerk selects the role from a list of roles and sets the time period. This use case is further described below
  • Step 1 The extended use case passes in the object identifiers for a person and an organization
  • Step 2 The link person to organization role module 1724 displays a form containing a list of roles ordered by name, displaying the Name and Desc ⁇ ption for each role, and entry fields for Start and End Dates
  • Step 3 The Data Entry Clerk selects a role and enters the Start Date (required) and optionally the End Date
  • Step 4 The link person to organization role module 1724 creates a link between the person, the role, and the organization in the Licensing database 1204 as an instance of Organization People and a time period using the Start and End Dates
  • the link person to organization role module 1724 creates an Open-Ended Period using that date ° ff the Data Entry Clerk supplies both a Start Date and an End Date, the link person to organization role module 1724 creates a Fixed Interval using those dates
  • the p ⁇ nt entity use case 2902 is diagramed in FIG 29
  • This use case extends the Print Object use case
  • the print entity module 1708 prints information on an Entity, including all information in the Licensing database 1204 about the entity, its relationships to other objects, and its contact information
  • the operation of this use case is further descnbed below Step 1
  • the Actor via the print entity module 1708 selects an Entity and selects a command to p ⁇ nt it
  • Step 2 The print entity module 1708 prints a formatted report with the Entity ID, Name, Description, and Named Entity Type (Organization or Person) Step 3
  • the p ⁇ nt entity module 1708 prints the contact information for the entity in p ⁇ o ⁇ ty order, p ⁇ nting the P ⁇ onty, Description, and Contact Method Type for each method
  • Step 4 The print entity module 1708 prints the Role Name and Know How Desc ⁇ ption for any Contnbutor relationship the Entity participates in
  • Step 5 The p ⁇ nt entity module 1708 p ⁇ nts the Role Name and Agreement Number and Name for any license agreement to which the Entity is a party
  • the print entity module 1708 prints the parent organization's Name and the Description of the Organizational Level of the organization
  • the p ⁇ nt entity module 1708 prints the
  • the print entity module 1708 prints the number in the format "+ ⁇ Country Telephone Code > ⁇ Area Code>
  • the print entity module 1708 prints the address in the format " ⁇ Address 1>, ⁇ Address 2>, ⁇ C ⁇ ty>, ⁇ State or Prov ⁇ nce>, ⁇ Country Abbreviations ⁇ Postal Code>"
  • the remove entity use case 12102 is diagramed in FIG 121 Accoiding to this use case, the Licensing system Administrator selects an entity and removes it from the Licensing database 1204 Preferably, an entity can be removed only if it does not participate as a party to a license agreement or as a contributor to a know-how asset In removing an entity, a number of different objects are also removed
  • Step 1 The License Administrator begins the transaction Step 2
  • the Remove entity module 1794 displays a list of existing entities ordered by name, displaying the name and entity type
  • the License Administrator can select and remove multiple entities at once oi in sequence At the end of the process, the License Administrator commits the transaction
  • Step 4 The Remove entity module 1794 deletes the entity, removing also the co ⁇ esponding subclass (Person or Organization), links to Organization for people, name fragments, and contact methods
  • Step 5 The Remove entity module 1794 confirms the commit to the License
  • the Remove entity module 1794 disallows removal and reports the error message " ⁇ Name> has one or more payments in the remove entity module 1794, so you cannot remove it " The
  • ⁇ Name> is the name of the entity
  • the application extends the use case with the Display Context-Sensitive Help use case.
  • the query entities use case 15402 is diagramed in FIG. 154.
  • This use case is used by the Link Payment to Entity use case to supply an entity to that use case for linking to a license payment.
  • the License Administrator queries a named entity from the Licensing Database 1204 based on any of the structured fields of the entity (name, description, and entity type).
  • the query entities module 15404 displays the name, description, and entity type of the named entities that match the query conditions and allows the License Administrator to select some for further processing in a using use case. The operation of this use case is further described below.
  • Step 1 The query entities module 15404 displays a query form with the name, description, and entity type fields available for specifying a query.
  • Step 2 The License Administrator enters the search criteria.
  • Step 3 The query entities module 15404 queries all the entities that meet the query criteria from the Licensing Database 1204.
  • the query entities module 15404 displays the entities, showing the name, description, and type.
  • Step 4 The License Administrator selects one or more entities for use in the using use case.
  • An asset is an intellectual property document (for example, patent, copyright, trademark, trade secret, etc.) or an intellectual asset (for example, know how).
  • assets are combined into asset packages, which may be standard (lists of assets), group (reference to an IPAM group, for example, described above), or descriptive (a text describing the assets with language from the license agreement).
  • a group as described above (sometimes herein refer to as an IPAM group) differs from an asset package.
  • the licensing system 1102 is integrated with the IPAM server 214, it is possible to create a type of an asset package (the IPAM group type) that links to a group and that acquires all of the documents associated with that group.
  • changes to the contents of the group automatically affect the asset package (in other embodiments, changes to the contents of the group do not automatically affect the asset package).
  • the asset package is said to be linked (where the link is said to be "active") or associated with the group. But the asset package itself is a separate object from that group.
  • Linking the package to a license agreement preferably means that the license licenses all of the assets in the package to the licensee, unless the license agreement indicates otherwise.
  • An asset view 3002 is displayed when the asset packages icon 1416 is pressed (FIG. 30).
  • the Asset View 3002 contains two panes. The first pane, called the asset packages pane 3004, displays a spreadsheet of asset packages, and the second pane, called the assets pane 3006, displays the assets in the asset package selected in the asset packages pane 3004.
  • Selecting an asset package in the asset packages pane 3004 displays the assets in that package in the assets pane 3006. Double-clicking on an asset package in the asset packages pane 3004 displays the asset package modification dialog, while double-clicking on the asset in the asset pane 3006 displays the asset modification dialog. You can enter a new package or asset by double-clicking on an empty record or clicking on the New button. If no package is selected, you create the new asset independently of any package; otherwise, you create the asset in the selected package. Clicking on a Find tool displays the Find Asset dialog (FIGS.64A and 65, for example), which lets you enter search conditions to search for an asset. The find tool may be accessed in a number of ways, such as from the tool bar or via the menu (see FIG. 67).
  • the enter patent use case 3102 is diagramed in FIG. 31.
  • the enter patent use case 3102 enables a Data Entry Clerk to enter information for a patent (U.S. or foreign) asset.
  • the patent can be packaged alone or with other assets into asset packages that can be licensed.
  • Step 1 The Data Entry Clerk starts a transaction to enter a new patent asset by issuing an appropriate command. This can be done, for example, by selecting New, Patent from the menu bar 1406 (FIG. 32).
  • the enter patent module 1730 displays a data entry form called an enter new patent dialog 3302 (FIG. 33) for input and generates an object identifier for the new asset.
  • the enter new patent dialog 3302 has two tabs, a general tab 3304 and a optional tab 3306.
  • the Data Entry Clerk chooses from a list of publishing organizations and document kinds. For example, the Data Entry Clerk can press a down a ⁇ ow key 3308 (FIG. 33) to view a list of available publishing organizations 3402 (FIG. 34). The Data Entry Clerk can press another down arrow key 3312 to view and choose from a list of different types of documents, such as utility patent, design patent, plant patent, SIR, provisional application, patent application, etc.
  • Step 4 The Data Entry Clerk enters data into the following fields in any order: Document Number, Long Display Name, Patent Type, and Filing Date.
  • the user can enter the following fields in any order: Description, Title, Filing Date, Issue Date, and Publication Date. See FIGS. 33 and 35.
  • the Data Entry Clerk sets the Security Class from a list of available security classes with Write privilege for the user.
  • Step 5 The Data Entry Clerk commits the transaction by pressing a save button 3310 (RG. 33).
  • Step 6 The enter patent module 1730 creates an IP Document, a Document, and an object of the appropriate subclass for the patent type in the Core Database
  • the enter patent module 1730 marks the Document as an IP Document.
  • the application extends the use case with the Display Help use case. ff the IPAM Server 214 and IPAM database 216 are available, the
  • Licensing System 1102 disallows entry of patent information via the enter patent module 1730. Essentially, the enter patent module 1730 cannot be accessed when the IPAM Server 214 and IPAM database 216 are available. Instead, all patent information is obtained from the PAM Server 214 and IPAM database 216.
  • the enter trademark use case 3602 is diagramed in FIG. 36.
  • the Data Entry Clerk enters information for a trademark asset, including the trademark classes and the kind of trademark (US Federal, State, WJPO, etc.).
  • Step 1 The Data Entry Clerk starts a transaction to enter a new trademark asset. This can be done in a number of ways, such as by selecting New, Trademark from the menu bar 1406 (FIG. 32).
  • Step 2. The enter trademark module 1732 displays a data entry form 3702 (FIG.37) for input of trademark information and generates an object identifier for the new asset.
  • the data entry form 3702 has a general tab 3704, an optional tab 3706, and a classes tab 3708.
  • Step 3 The Data Entry Clerk chooses from a list 3802 of publishing organizations (FIG. 38) and document/trademark kinds (by pressing a down arrow key 3712 to display a list of document/trademark kinds, where such document/trademark kinds are any known types).
  • Step 4 The Data Entry Clerk enters data into the following fields in any order: Doc Kind, Document Number, Long Display Name, and Filing Date.
  • the user can enter the following fields in any order: Description, Title, Filing Date, Issue Date, and Publication Date.
  • the Data Entry Clerk enters a set of Trademark Classes from a list of classes.
  • the Data Entry Clerk sets the Security Class from a list of available security classes with Write privilege for the user. See FIGS. 37-40.
  • Step 5 The Data Entry Clerk cornmits the transaction by pressing a save button 3804.
  • the enter trademark module 1732 creates an IP Document, a Document, an object of class Trademark, and an association object relating the trademark to a series of Trademark Classes in the Licensing Database 1204.
  • the enter trademark module 1732 marks the Document as an IP Document.
  • the enter copyright use case 4102 is diagramed in FIG. 41.
  • the Data Entry Clerk enters basic information for a copyright asset.
  • Step 1 The Data Entry Clerk starts a transaction to enter a new copyright asset This can be done in a number of ways, such as by selecting New, Copyright from the menu bar 1406 (FIG. 32).
  • Step 2 The enter copy ⁇ ght module 1734 displays a data entry form 4202 (FIG.42) for input and generates an object identifier for the new asset.
  • the data entry form 4202 has a general tab 4206 and an optional tab 4208.
  • Step 3 The Data Entry Clerk chooses from a list of publishing organizations and document kinds See, for example, FIG. 43.
  • Step 4 The Data Entry Clerk enters data into the following fields in any order Document Number, Long Display Name, and Filing Date. Optionally, the usei can enter the following fields in any order: Description, Title, Filing Date, Issue Date, and Publication Date.
  • the Data Entry Clerk sets the Security Class from a list of available secu ⁇ ty classes with Write privilege for the user. See FIGS. 42-44
  • Step 5 The Data Entry Clerk commits the transaction by pressing a save button 4204
  • the enter copyright module 1734 creates an IP Document, a Document, and an object of class Copyright in the Licensing Database 1204.
  • the enter copyright module 1734 marks the Document as an IP Document
  • the enter trade secret use case 4502 is diagramed in FIG. 45 According to this use case, the Data Entry Clerk enters information for a Trade Secret asset
  • enter trade secret use case 4502 The operation of the enter trade secret use case 4502 is further described below:
  • Step 1 The Data Entry Clerk starts a transaction to enter a new trade secret asset using any procedure desc ⁇ bed herein.
  • the enter trade secret module 1736 displays a data entry form for input and generates an object identifier for the new asset.
  • Step 3 The Data Entry Clerk chooses from a list of publishing organizations and document kinds.
  • Step 4 The Data Entry Clerk enters data into the following fields in any order: Document Number, Long Display Name, and Filing Date. Optionally, the user can enter the following fields in any order: Description, Title, Filing Date, Issue Date, and Publication Date.
  • the Data Entry Clerk sets the Security Class from a list of available security classes with Write privilege for the user.
  • Step 5. The Data Entry Clerk commits the transaction.
  • the enter trade secret module 1736 creates an IP Document, a Document, and an object of class Trade Secret in the Licensing Database 1204.
  • the enter trade secret module 1736 marks the Document as a type of know how.
  • the enter know how use case 4602 is diagramed in FIG.46.
  • the Data Entry Clerk enters information for a Know-How asset into the Licensing Database 1204.
  • the operation of this use case is further described below:
  • Step 1 The Data Entry Clerk starts a transaction to enter a new know how asset. This can be done in a number of ways, such as by selecting New, Know How from the menu bar 1406 (FIG. 32).
  • Step 2 The enter know how module 1738 displays a data entry form 4702 (FIG. 223) for input and generates an object identifier for the new asset.
  • Step 3 The Data Entry Clerk enters various items: Step 3.1.
  • the Data Entry Clerk sets the Description of the know how by entering text.
  • the Data Entry Clerk can also link this asset to one or more other objects (such as documents, figures, software programs, etc.) that represent or illustrate the know how asset.
  • the Data Entry Clerk chooses from a list of intellectual asset kinds. This list can include any standard or use defined terms describing intellectual asset kinds, and could be based on technology area, market area, industrial area, corporate organization level, etc.
  • Step 3.3 The Data Entry Clerk sets the Security Class from a list of available security classes with Write privilege for the user.
  • the security class indicates the users who have access to this record.
  • Step 4. The Data Entry Clerk commits the transaction.
  • Step 5. The enter know how module 1738 creates a Document and an object of class Know How in the Licensing Database 1204. The enter know how module 1738 marks the Document as a Know How.
  • the modify IP asset use case 4802 is diagramed in FIG.48. According to this use case, the License Administrator queries an IP asset and modifies it. The operation of this use case is further described below.
  • Step 1 The License Administrator begins the transaction to modify an IP asset using any of the techniques described herein.
  • the modify IP asset module 1740 uses the Query Assets module 1742 to display a set of assets and to allow the License Administrator to select one for modification. Step 3. ff the License Administrator has Write permission on the selected asset, the IP asset module 1740 displays a form containing, for example, these fields for the asset document: Document Number, Title, Long Display Name, Issue Date, Filing Date, Publication Date, Description, Asset Type ("Disc Switch"), Publishing Organization (Description from Pub Organization class), and Doc Kind (Description from IP Doc Kind class).
  • Step 4 The License Administrator modifies any of the fields in any order and signals the end of the transaction.
  • Step 5 The IP asset module 1740 writes the changes to the licensing database 1204 or the core database 1208 and confirms the commit to the License
  • the asset is a patent from the IPAM database 216, the user cannot modify any of the asset details. If the asset is a patent (JPO_PATENT, EPO_PATENT, PCT, or
  • PTO_PATENT classes the extended fields include Assignee, Class, Intemationai Class, and Inventor.
  • An asset package includes one or more IP assets. Use cases related to asset packages are described below. Create IP Asset Package
  • the create IP asset package use case 4902 is diagramed m FIG 49
  • the License Administrator creates a named package of intellectual property (IP) assets in the Licensing Database 1204 All or part of this asset package (possibly along with one or more other asset packages) may then be licensed via a license agreement
  • An asset package can be generated m a numbei of ways by querying the assets from the Licensing Database 1204, by querying a gioup from the Core Database 1208, or by entering a textual definition of the assets
  • the operation of this use case is further desc ⁇ bed below Step 1
  • the License Administrator begins the transaction to create a new IP asset package This can be done in a number of ways, such as by selecting New, Asset Package from the menu bar 1406 (FIG 32)
  • Step 2 The create IP asset package module 1744 displays an asset package dialog 5002 (FIG 50) From a pull down list 5004, the License Administrator chooses the type of asset package to create (Asset/Standard, Group, or Descriptive
  • the Asset/Standard type is an asset package containing any combination of assets selected by the user
  • the Group type is an asset package containing the assets included in one or more pre-existing groups
  • the Descriptive Package type is an asset package whose assets are indicated by way of a desc ⁇ ption, such as a textual desc ⁇ ption, an audio desc ⁇ ption, a multimedia desc ⁇ ption (the files for those media types may be linked to this record)
  • Step 3 The create IP asset package module 1744 creates a new package with a new object identifier
  • Step 4 The License Administrator enters a Name for the package Optionally, and in any order, the License Administrator enters the Description and/or the captui e period (Start and End timestamps) See FIG 51 ff the Asset/Standard type is selected, then an asset/standard type dialog 5102 is displayed (FIG 51)
  • the asset standard type dialog 5102 has a general tab 5104, assets tab 5106, and allocation tab 5108.
  • the License Administrator can use the Query Assets module 1742 to query a set of asset documents from the Licensing Database 1204 for the package.
  • the create IP asset package module 1744 links these documents to the new package.
  • the new assets are listed in the assets tab 5106 (FIG. 52).
  • the License Administrator can choose to allocate the assets within the package.
  • the create IP asset package module 1744 displays a list of the assets in the package, and the License Administrator enters an Allocation Percent for each asset. See FIG. 53.
  • the License Administrator can select an even distribution or a custom distribution, where relative percentages are entered by the License Administrator.
  • a group dialog 5402 is displayed (FIG. 54) having a general tab 5104, a group tab 23004, and an allocation tab 5108.
  • the create IP asset package module 1744 displays a list of group names from the Core Database
  • the License Administrator as a User must have the ability to read the groups in the list.
  • the License Administrator selects one or more groups that hold the documents/assets that the package is to package.
  • the create IP asset package module 1744 displays the group documents and links them to the package in the group tab 5404 (FIG. 55).
  • ff the Descriptive type is selected, then a descriptive dialog 5602 is displayed (FIG. 56) having a general tab 5104 and a description tab 5604.
  • the License Administrator enters text regarding Inclusion Criteria that describes the legal qualities of the assets, preferably in the language from the Licensing Agreement, in addition to the Standard behavior. See FIG. 57.
  • Step 5 The create IP asset package module 1744 writes the new asset package to the Licensing Database 1204, making the License Administrator user the owner of the package, then confirms the transaction commit to the License
  • the modify IP asset package use case 5802 is diagramed in FIG. 58.
  • the License Administrator selects an IP Asset Package from the Licensing Database 1204, then modifies the information about the package and/or its contents: the documents listed in a standard package, the group contained within a Group package, or the text contained within a Descriptive package. The operation of this use case is further described below.
  • Step 1 The License Administrator starts the transaction to edit an IP asset package. This can be done, for example, by selecting the asset packages icon 1416 to display an asset package view 5902.
  • the asset package view 5902 has a package list pane 5904 where asset packages are listed, and an asset list pane 5906 where assets in a selected asset package (selected in the package list pane 5904) are listed.
  • the modify IP asset package module 1746 displays the asset packages in the packages list pane 5904 by querying the Licensing Database 1204, preferably displaying the Name, Description, and/or Package Type preferably in alphabetical order by name.
  • the modify IP asset package module 1746 displays only those packages for which the License Administrator has Read permission or ownership.
  • Step 3 The License Administrator selects a package in the packages list pane 5904.
  • Step 4 If the License Administrator has Write permission on the selected package or owns it, the modify IP asset package module 1746 displays a form showing all the fields of the package, including the object identifier, the Package Name, the Description, the capture period (Start and End date/time), and the Package Type. This is similar to the examples shown in FIGS. 50-57.
  • Step 5 The License Administrator changes the Name, Description, Capture Period, Package Type, or other information in any order, then ends the transaction.
  • Step 6 The modify IP asset package module 1746 updates the Licensing Database 1204 with the changes and confirms the commit to the License Administrator.
  • This use case has a number of extensions: ° ff the License Administrator changes Package Type, the modify IP asset package module 1746 uses the same logic as in the Create IP Asset Package use case 4902 to create a new subclass for the package with the appropriate contents. The modify IP asset package module 1746 removes any asset allocation percents. The modify IP asset package module 1746 can undo the change until the License Administrator ends the transaction.
  • the modify IP asset package module 1746 displays a list of assets.
  • the License Administrator can add or remove assets from the list.
  • the License Administrator uses the Query Assets use case to query a set of additional asset documents from the Core Database 1208 for the package.
  • the modify IP asset package module 1746 links these documents to the new package.
  • the License Administrator selects and removes asset documents.
  • the License Administrator adjusts the Allocation Percent of each asset as required.
  • the modify IP asset package module 1746 displays the Name and Description of the group.
  • the License Administrator can change the group by selecting from a list of available groups
  • the modify IP asset package module 1746 displays a list of group names from the Core Database 1208 in alphabetical order. The License Administrator as a User must have the ability to read the groups in the list. The License Administrator selects a group that holds the documents that the package packages. The modify IP asset package module 1746 displays the group documents and links them to the package. The modify IP asset package module 1746 removes current Allocation Percent values (all links get deleted). ° ff the Package is a Descriptive package, the modify IP asset package module 1746 displays the Description. The License Administrator can change the Description by editing the text.
  • the modify IP asset package module 1746 displays the cu ⁇ ent allocations and the Administrator changes them.
  • the print asset package use case 6002 is diagramed in FIG. 60. This use case extends the Print Object use case, and the Print License use case uses it.
  • the print asset package module 1710 prints an Asset Package, including all information in the Licensing Database 1204 and the Core Database 1208 about the package and its documents . The operation of the print asset package module 1710 is further described below.
  • Step 1 The Actor in the Print Object use case or the Print License Use case selects an Asset Package and prints it.
  • Step 2. The print asset package module 1710 prints a formatted report with the Start Date, End Date, Name, Description, Package Type, etc. It then prints package-specific information (see Extensions).
  • Step 3 The print asset package module 1710 prints the Document IDs of the documents and the document-specific information (see Extensions). This use case has a number of extensions: ° If the package is a Descriptive Asset Package, the print asset package module 1710 prints the Inclusion Criteria for the package and does not print any documents.
  • the print asset package module 1710 prints the Group ID, Name, and Description of the group and prints the
  • the print asset package module 1710 prints the Publishing Organization Description, the IP Doc Kind Description, the Document Number, the Title, and the Description.
  • the print asset package module 1710 prints the Intellectual Asset Kind Description and the Description.
  • a Document is a User Defined Document (UDD)
  • the print asset package module 1710 prints information pertaining to the document.
  • the remove IP asset use case 6102 is diagramed in FIG. 61. This is preferably an administrator use case. According to this use case, the licensing system administrator removes an IP asset (an IP Document or a Know How document, for example) and its related data from the Licensing Database 1204 and Core Database
  • Step 1 The System administrator begins the transaction.
  • Step 2 The remove JP asset module 1703 displays a list of all assets (the IP
  • Step 3. The Administrator selects one or more assets and removes them..
  • Step 4 The remove IP asset module 1703 deletes the information from the Licensing and Core databases 1204 and 1208 and moves it to the Recycle Bin (implementation may differ, deferring the actual SQL deletes, and there is no notification of commit to the Administrator).
  • the administrator can restore the removed Asset.
  • IP_Document and Document classes are done with Administrator privileges in the
  • the remove IP asset package use case 6202 is diagramed in FIG. 62.
  • the License Administrator selects an asset package from a list and removes it from the Licensing Database 1204, subject to security access and links to license agreements.
  • the operation of this use case is further described below.
  • Step 1 The License Administrator begins a transaction.
  • the remove ff asset package module 1748 displays a list of the asset packages to which the user has Read access or which the user owns, displaying the object identifier, the Name, the Description, and the Package Type, ordered by Name.
  • the License Administrator selects one or more asset packages to which the user has Delete access or which the user owns and removes them. The License Administrator then commits the transaction.
  • the remove IP asset package module 1748 removes the persistent asset packages from the Licensing Database 1204 and confirms the operation to the License Administrator.
  • the remove IP asset package module 1748 propagates the delete to the appropriate subclass based on Package_Type (Standard Asset Package, Descriptive Asset Package, Group Asset Package) and to the Secure Object superclass.
  • This use case has a number of extensions.
  • the remove IP asset package module 1748 does not allow removal, displaying the error message "The ⁇ oid> license agreement uses this asset package; you cannot remove it.”
  • ⁇ oid> is the object identifier for the license agreement.
  • the application extends the use case with the Display Context-Sensitive Help use case.
  • the query assets use case 6302 is diagramed in FIG.63. This use case is used by other use cases.
  • the License Administrator queries the Licensing Database 1204 for a set of asset documents by entering search criteria into a form (see FIGS. 64-66, for example). The License Administrator can remove assets from this set individually.
  • the use case returns a set of License object identifiers (OIDs). The operation of this use case is further described below.
  • Step 1 The using use case calls this use case, and the query assets module 1742 displays, for example, a screen that contains these fields for search criteria: Document Number, Title, Long Display Name, Issue Date, Filing Date, Publication Date, Description, Asset Type ("Disc Switch"), Publishing Organization (Description from Pub Organization class), Doc Kind (Description from IP Doc Kind class), and/or any other search fields discussed herein, or conventionally used. See example displays in FIGS. 64A, 64B, and 65.
  • Step 2 The License Administrator enters one or more fields of search criteria and submits the query.
  • the query assets module 1742 displays a list of documents 6602 that satisfy the query, displaying the Asset Type, Document Number, and Title (for ff documents) and/or LA Kind and Description (for Know How), and to which the
  • License Administrator has READ access. See FIGS. 64B and 66.
  • Step4. The License Administrator may take any numberof actions, including one of these actions:
  • Step 4.1 The License Administrator may select an asset for editing (Modify ff Asset use case).
  • Step 4.2 The License Administrator may drag and drop or copy and paste an asset into a list of assets (Create or Modify IP Asset Package).
  • Step 5. The License Administrator ends the use case.
  • This use case has a number of extensions: ff the asset is a patent (JPO_PATENT, EPOJPATENT, PCT, or
  • the extended search criteria includes Assignee, Class, International Class, and Inventor.
  • the extended search criteria includes
  • the extended search criteria includes the LA kind Description and the Know How Description.
  • the application extends the use case with the Display Help use case.
  • the query asset packages use case 15902 is diagramed in FIG. 159.
  • the Auditor, the Data Entry Clerk, or the License Administrator queries an asset package from the Licensing Database 1204 based on any of the structured fields of the package (including inclusion criteria for descriptive asset packages and group name and description for group packages) or the list of assets (documents) associated with the package.
  • the query asset package module 33504 displays the set of asset packages that qualify given the search criteria.
  • the Modify Asset Package use case extends this one, enabling the actor to modify a package found through the query. This use case is further described below.
  • Step 1 The Actor begins the transaction.
  • Step 2. The query asset package module 15904 displays a form that allows the
  • Step 4 The query asset package module 15904 concatenates all the conditions with a logical AND, then queries the Licensing Database 1204 using the resulting search condition. The query asset package module 15904 then displays a list of all the asset packages that satisfy the search condition. The query asset package module 15904 displays the Package Name, Description, and Package Type.
  • Step 5 The Actor ends the transaction.
  • This use case has a number of extensions: ° If the Actor selects a Package Type of Standard or Descriptive, the query asset package module 15904 displays an additional form that allows the user to enter a search expression that specifies a logical conditional expression of ANDs, ORs, and NOTs (with parenthetical grouping) combining assets ((Asset 1 AND Asset 2) OR Asset 3) which it gathers with the Query Assets use case.
  • the query asset package module 15904 queries the Licensing Database to find those packages with the appropriate combination of assets.
  • the query asset package module 15904 displays an additional form that allows the user to enter a text search on Inclusion Criteria.
  • the query asset package module 15904 queries the Licensing Database to find those Descriptive packages that qualify.
  • the query asset package module 15904 displays an additional form that allows the user to enter a text search on Group Name and/or Group Description. As well, the query asset package module 15904 displays a form for entering a search expression for grouped documents with AND, OR, and NOT relational operators as for Standard or Descriptive packages . The query asset package module 15904 queries the Licensing Database to find those group packages with the appropriate combination of assets.
  • a license agreement is a contract in which an entity, the licensor, licenses intellectual property to another entity, the licensee. There may be a plurality of licensors and/or licensees.
  • the license agreement in the context of the present invention contains definitions of the parties to the agreement, compensation terms, territorial restrictions, field-of-use (market area) restrictions, and any other terms and or clauses used in license agreements.
  • a License Agreements View 6802 (FIG. 68) displays a spreadsheet pane of all the license agreements. Double-clicking on a license displays the agreement modification dialog 6902 (FIG.69). This dialog 6902 displays five tabs.
  • the General tab 6904 shown here contains the basic information about the agreement.
  • the Asset Packages tab 6906 lists the asset packages that are the subject of the license and lets the License Administrator administer the list.
  • the Terms tab 6908 lists the compensation terms of the license (fees, royalties, advances, minimum guarantees, and other). The License Administrator can modify these terms through that tab.
  • the License Administrator can modify these terms through that tab.
  • Royalty Statements tab 6910 and Payments tabs 6912 let the License Administrator see the linked statements and payments related to the license, but not modify them.
  • Double-clicking on the empty row or on the new button in the license agreements view 6802 displays the license creation dialog 7202 (FIG.72). This dialog is the same as the modification dialog but does not display the Statements and Payments tabs, as a new license has none.
  • Selecting a Find tool in this view displays the Find Agreement dialog 7002 (FIG. 70), which lets you enter search terms for agreements. Entering search conditions into this dialog 7002 and clicking on Find Now displays the matching agreements in the extended dialog 7102 (FIG. 71). You can then double-click on the agreement to display the modification dialog with all the details of the license.
  • the enter license agreement use case 7302 is diagramed in FIG. 73. According to this use case, the Data Entry Clerk enters a license agreement into the
  • the Data Entry Clerk enters a set of compensation terms that describe the fee and royalty structure of the agreement.
  • the Data Entry Clerk also links the agreement to a set of asset packages representing the licensed ff assets and to the various parties to the agreement (licensor, licensees, attorneys, and so on). The operation of this use case is further described below. Step 1.
  • the Data Entry Clerk begins the transaction.
  • Step 2 The enter license agreement module 1750 generates a new object identifier for the license agreement and displays a data entry form 7202 for the new license.
  • Step 3 The Data Entry Clerk enters data into the structured data fields of the license creation dialog 7202 and links other objects as required:
  • Step 3.1 The Data Entry Clerk enters the structured fields of the agreement: the Agreement LD, the Title/Name, Description, Effective Date, Expiration Date, Exclusivity, Assignable, Transferable, Revocable, Confidential, Terminated, etc.
  • Step 3.2 The Data Entry Clerk enters the structured fields of the license agreement: Perpetual, Infringement Based (see Extensions), Can Sublicense, Annual Audit, Audit at Licensee Expense, Favored Nation, Improvements, Grant Back, Withholding Percentage, etc.
  • Step3.3 The Data Entry Clerk uses the Link to Asset Packages use case to specify the set of asset packages for the license. These linked asset packages are displayed in the asset packages tab 6906.
  • Step 3.4 The Data Entry Clerk uses the Enter Compensation
  • Step 3.5 The Data Entry Clerk uses the Link to Party use case to specify a party to the agreement.
  • Required parties include one licensor and at least one licensee. You can also add other parties such as attorneys and other roles entered through the Add Role use case by the License System Administrator. This step repeats until the clerk has linked all the parties to the agreement.
  • This information is displayed in the Licensor and Licensee fields (FIG 72)
  • Step 3 6 The Data Entry Clerk selects the Secu ⁇ ty Class for the new document from a list of available secu ⁇ ty classes, which control who has access to this license
  • Step 4 The Data Entry Clerk commits the transaction Step 5
  • the enter license agreement module 1750 creates the License Agreement or Inf ⁇ ngement Based Agreement m the Licensing Database 1204
  • the enter license agreement module 1750 confirms the commit to the Data Entry Clerk This use case has a number of extensions
  • Entity use case to create the approp ⁇ ate entity ° ff the Data Entry Clerk indicates that the license agreement is inf ⁇ ngement based, create an Infr Based Agreement rather than a License Agreement and add the Infringement Release Granted flag and the Infringement Comment field to the data entry form
  • a license is infringement based if it resulted or is somehow associated with or related to an allegation of inf ⁇ ngement (whether or not an infringement suit was filed in court)
  • An embodiment of the invention supports additional information that you track for infringement based license agreements
  • the link to party use case 7402 is diagramed in FIG 74 According to this use case, a Data Entry Clerk selects an entity from a list and a role from anothei list
  • the Licensing Database 1204 creates a link between the entity, the role, and the license agreement from the using use case. This use case is further described below.
  • Step 1 The Data Entry Clerk starts the use case with an open transaction containing a license agreement that will link to the entity and role, passing in the object identifier for the license agreement.
  • Step 2 The link to party module 1756 queries the Licensing database 1204 and displays the names and descriptions of the entities and roles.
  • Step 3 The Data Entry Clerk selects one entity from the entity list and one role from the role list.
  • Step 4. The Data Entry Clerk signals the end of the use case.
  • Step 5 The Licensing Database 1204 creates a Party link using the License Agreement OLD, the Entity OLD, and the Role OLD.
  • This use case has a number of extensions.
  • the link to asset package use case 7502 is diagramed in FIG. 75.
  • a Data Entry Clerk selects one or more asset packages from a list.
  • the link to asset package module 1752 creates a link between the input license agreement and the selected asset packages.
  • the Data Entry Clerk sets the territorial and field-of-use restrictions (and any other license details) on each asset package link.
  • the Data Entry Clerk indicates whether the link is a cross license and/or has any further limitations, obligations, rights, etc. as part of this license.
  • the link to asset package module 1752 is further described below. Step 1.
  • the Data Entry Clerk starts the use case with an open transaction containing a license agreement that will link to the asset packages.
  • the extended use case supplies the object identifier for the agreement.
  • Step 2 The link to asset package module 1752 displays the names and descriptions of the asset packages in a list ordered by name.
  • Step 3 The Data Entry Clerk selects one or more packages from the list.
  • Step 4 The link to asset package module 1752 creates and displays a link between the license agreement and each package the Data Entry Clerk selects and assigns default territorial and field-of-use values.
  • the link to asset package module 1752 sets the default Cross-Licensed flag to false.
  • Step 5 The Data Entry Clerk adds temtorial and field-of-use restrictions to the links using lists of the available territories and fields of use from the Licensing Database 1204.
  • the Data Entry Clerk also sets the Cross-License flag to true if the particular package represents assets licensed by the licensee to the licensor instead of vice versa.
  • the Data Entry Clerk removes unwanted territorial and field-of-use restrictions from the links.
  • the Data Entry Clerk enters any additional limitations in the Limitations field. All of these actions may occur in any order.
  • the Data Entry Clerk signals the end of the use case.
  • Step 6 The Licensing Database 1204 links the asset packages and the input license agreement and adds links to the required territories and fields of use for each link.
  • the enter compensation term use case 7602 is diagramed in FIG. 76.
  • the Enter License Agreement and Modify License Agreement use cases use this one to enter compensation terms to a license agreement in the Licensing Database 1204.
  • the Licensing Administrator or Data Entry Clerk creates a licensing term with the details appropriate to the particular term. All terms have a description, an amount, and late payment penalties, and perhaps other attributes.
  • Ongoing royalties have a time period and possibly tables of escalating amounts based on number of units/sales plus tables of estimated number of units/sales. Ongoing royalties break down into royalties on units sold, on revenue, or on revenue from sublicense royalties. A minimum guarantee also has a time period and possible escalations.
  • An advance has a due date and may be refundable or not. A fee may be ongoing with a time period or a lump sum fee with a due date.
  • Step 1 The using use case passes in the object identifier for the license agreement to which the Data Entry Clerk or License Administrator (the Actor) wants to add compensation terms.
  • the enter compensation term module 1754 displays a list of the current set of compensation terms (if any) for this license, preferably in order of term number, displaying the term Description, the compounding period Description, the
  • Step 3 The Actor creates a new term and selects one of the term types (Royalty Per Unit, Royalty Per Sales Amount, Royalty Per Royalty Amount, Minimum Guarantee, Advance, Ongoing Fee, Lump Sum Fee, or Other).
  • the enter compensation term module 1754 displays the term with default values (Amount 0, Currency from the last term or the default currency for the system, interest rate 0, fields for entering a Time Unit Period (see Extensions) with default Time Unit Type of Month, Term Type, Royalty_Per_Sales_Amount).
  • the enter compensation term module 1754 displays a form for the term given the default term type (see Extensions). It displays a choice of several period types and entry fields that differ depending on the period type the user chooses.
  • Step 5 The Actor enters the standard details for the term and the details for the particular term type (see Extensions), then either repeats from step 3 or ends the use case.
  • Step 6 The enter compensation term module 1754 inserts the new terms into the Licensing Database 12404.
  • the enter compensation term module 1754 extends the use case with the Create Expected Revenue use case, which computes the expected revenue amounts per period for the existing compensation terms.
  • the application extends the use case with the Display Help use case.
  • ° ff the term type is Ongoing Royalty
  • the enter compensation term module 1754 displays fields for entering a Recurring Period (see below) and an ongoing royalty type (Per Unit, Per Sales, Per Royalty (Sublicense), default Per Sales.
  • the enter compensation term module 1754 displays fields for entering a Royalty Unit (default 'Unit'), the Estimated Number of Units per Period (default 0), a table for an escalation schedule (Starting Units, Ending Units, and Amount), and a table for Estimated Units (Period Number, Estimated Units).
  • the enter compensation term module 1754 displays fields for entering the Percentage, the Net flag (default True) , the Estimated Revenue Per Period
  • the enter compensation term module 1754 displays the same fields as for Royalty Per Sales Amount.
  • the enter compensation term module 1754 displays fields for entering a Time Unit Period (see below), a Due
  • the enter compensation term module 1754 displays fields for entering a Time Unit Period (see below).
  • the enter compensation term module 1754 displays the Due Date.
  • the enter compensation term module 1754 displays the Time Unit Type, the Start Date, the Recu ⁇ ence Rate, the Starting Interval, the Interval Unit Type, and the choice of ending the cycle with a specific number of recurrences (Recu ⁇ ing Period) or a specific End Date (End Date
  • the create expected revenue use case 7702 is diagramed in FIG.77.
  • This use case extends the Enter Compensation Term use case to build a series of expected future revenue payments. In other words, based on the compensation terms of the license agreement, it is possible for the invention to calculate expected revenue to be generated in the future by the license agreement. Such expected future revenue can then be compared to actual revenue.
  • the extending use case passes in the compensation term object identifier.
  • the create expected revenue module 1760 queries the compensation term and its components and generates the appropriate payments expected from that term.
  • Step 1 The create expected revenue module 1760 queries the Compensation Term in question from the Licensing Database 1204 to get the Amount and subtype of the term.
  • Step 2 For each period that is part of the structure of the compensation term, the create expected revenue module 1760 creates an Expected License Revenue object in the Licensing Database 1204, giving it a payment number and a due date as well as the expected amount of the payment.
  • Step 3 The create expected revenue module 1760 iterates through the expected revenues calculated in step 2 to subtract advance payment amounts from expected royalties and to reset Minimum Guarantees to the amount needed to bring the guarantee up to the guaranteed amount.
  • the create expected revenue module 1760 queries the time period, the scaling royalty structure, and the royalty type. ° For a Royalty Per Unit, the Create expected revenue module 1760 queries the Estimated Units Per Period and the set of period estimates. Using this information, the time period, and the scaling royalty structure, the Create expected revenue module 1760 computes the series of royalty payments due through the expiration of the license.
  • the Description is "Per-unit royalty for the period from ⁇ start> to ⁇ end> at ⁇ Amount> ⁇ currency symbol> per ⁇ unit> [using scaled royalty from ⁇ starting units> to ⁇ ending units>]".
  • the ⁇ start> and ⁇ end> are the computed period boundaries, the Amount is the term amount, the ⁇ cu ⁇ ency symbol> is the term Unit Symbol, the ⁇ unit> is the Unit from the Ongoing Royalty, and the optional string exists only for scaling royalties and lists the Starting Units and Ending Units from the Ongoing Royalty.
  • the Create expected revenue module 1760 queries the Estimated Revenue Per Period and the set of period estimates. Using this information, the time period, and the scaling royalty structure, the Create expected revenue module 1760 computes the series of royalty payments due through the expiration of the license.
  • the Description is "Revenue-based [sublicense] royalty for the period from ⁇ start> to ⁇ end> at ⁇ Percentage> per ⁇ currency unit> of revenue [using scaled royalty from ⁇ starting units> to ⁇ ending units>]”.
  • the optional "sublicense” string appears when the object is a Royalty Per Royalty Amount.
  • ⁇ start> and ⁇ end> are the computed period boundaries
  • the Percentage is the Royalty Per Sales Amount Percentage
  • the ⁇ currency unit> is the Unit Symbol for the term currency.
  • the optional string exists only for scaling royalties and lists the Starting Units and Ending Units from the Ongoing Royalty.
  • the Create expected revenue module 1760 queries the time period, the Due Date, and the scaling guarantee structure. Using this information, the Create expected revenue module 1760 computes the series of guarantee dates, setting the Expected Revenue Amount to the term Amount given the scaling table based on the Due Date.
  • the Description is "Minimum Guarantee for period from ⁇ start> to ⁇ end> using scaled guarantee for ⁇ Due Date>" , where ⁇ start> and ⁇ end> are the guarantee period boundaries and the ⁇ Due Date> is the Due Date of the actual scaling term used.
  • the Create expected revenue module 1760 queries the due date.
  • the Create expected revenue module 1760 sets the Amount to the term amount and the Due Date to the term Due Date.
  • the Description is "Advance on royalties due to be paid on ⁇ Due Date>”.
  • the Create expected revenue module 1760 queries the fee type. ° For an Ongoing Fee, the Create expected revenue module 1760 queries the time period. Using this information, the Create expected revenue module
  • the Amount is the term amount.
  • the Description is "Ongoing fee for period from ⁇ start> to ⁇ end>", where ⁇ start> and ⁇ end> are the time period boundaries.
  • the Create expected revenue module 1760 sets the Amount to the term amount and the Due Date to the Lump Sum Fee due date.
  • the Description is "Lump-sum fee due on ⁇ Due Date>”.
  • the Create expected revenue module 1760 queries the Description and Due Date and sets the Expected Revenue Amount to 0 and the DueJDate to the Other Compensation Due Date.
  • the Description is the term Description.
  • the modify compensation term use case 7802 is diagramed in FIG. 78.
  • the Modify License Agreement use case uses this one to change existing compensation terms that belong to a license agreement in the Licensing Database 1204.
  • Licensing Administrator selects a particular term and modifies its attributes. The operation of this use case is further described below.
  • Step 1 The using use case passes in the object identifier for the license agreement in which the License Administrator wants to change compensation terms.
  • Step 2 The modify compensation term module 1762 displays a list of the current set of compensation terms for this license in order of term number, displaying the term Description and the Term Type.
  • Step 3 The License Administrator selects a term for modification.
  • Step 4. The modify compensation term module 1762 displays the cu ⁇ ent values. It displays a data entry form for the term given the term type (see Extensions) that display the current values for the selected term.
  • Step 5. The License Administrator changes any of these values, then ends the use case.
  • Step 6 The modify compensation term module 1762 updates the term in the Licensing Database 1204. This use case has a number of extensions:
  • the application extends the use case with the Display Help use case.
  • the Modify compensation term module 1762 displays fields for entering a Time Unit Period (see below) and an ongoing royalty type (Per Unit, Per Sales, Per Royalty (Sublicense), default Per Sales.
  • Modify compensation term module 1762 displays fields for entering a
  • the Modify compensation term module 1762 displays fields for entering the Percentage, the Net flag (default True), the Estimated Revenue Per Period (default 0), a table for an escalation schedule (Starting Amount, Ending Amount, and Royalty Percentage), and a table for Estimated Revenue (Period Number, Estimated
  • the Modify compensation term module 1762 displays the same fields as for Royalty Per Sales Amount. ° If the Term Type is Minimum Guarantee, the Modify compensation term module 1762 displays fields for entering a Time Unit Period (see below), a Due Date, and a table for an escalation schedule (Start Date, End Date, Amount).
  • the Modify compensation term module 1762 displays the Due Date of the advance and the Refundable flag. ° ff the Term Type is Fee and the Fee Type is Ongoing Fee, the Modify compensation term module 1762 displays fields for entering a Time Unit Period (see below).
  • the Modify compensation term module 1762 displays the Due Date.
  • Modify compensation term module 1762 displays the Time Unit Type, the Start Date, the Recu ⁇ ence Rate, the Starting Interval, the Interval Unit Type, and the choice of ending the cycle with a specific number of recu ⁇ ences (Recumng Period) or a specific End Date (End Date Period).
  • the remove compensation term use case 7902 is diagramed in FIG.79.
  • Modify License Agreement use case uses this one to remove existing compensation terms that belong to a license agreement in the Licensing Database 1204.
  • the Licensing Administrator selects a particular term and removes it. The operation of this use case is further described below.
  • Step 1 The using use case passes in the object identifier for the license agreement in which the License Administrator wants to change compensation terms.
  • Step 2 The Remove compensation term module 1764 displays a list of the cu ⁇ ent set of compensation terms for this license in order of term number, displaying the term Description and the Term Type.
  • Step 3 The License Administrator selects a term to remove.
  • Step 4 The Remove compensation term module 1764 deletes the information from the Licensing Database and moves it to the Recycle Bin (implementation may differ regarding deferring the actual SQL deletes, and there is no notification of commit to the Administrator).
  • Query License
  • the query license use case 8002 is diagramed in FIG. 80.
  • the Auditor, the Data Entry Clerk, or the License Administrator queries a license from the Licensing Database 1204 based on any of the structured fields of the license.
  • the system displays the details of the license agreement, including a list of asset packages, the parties to the agreement, a list of compensation terms, a list of royalty statements, etc. The operation of this use case is further described below.
  • Step 1 The Auditor starts the transaction. This can be accomplished in a number of ways, such as by selecting Tools, Find, License Agreement from the menu bar (FIG. 67).
  • the Query license module 1768 displays a query form 8102 (FIG. 81 ) with any combination of the following structured fields available for query specification: object identifier, Agreement ID, Name, Title, Licensee, Licensor, Description, Effective Date, Exclusivity, Assignable, Transferable, Revocable,
  • Step 3 The Auditor enters the search criteria.
  • Step 4 The Query license module 1768 queries all the licenses that meet the query criteria from the licensing database 1204 and for which the Auditor has Read access.
  • the Query license module 1768 displays the licenses, preferably showing all of the fields in step 2 except for Party Name, Asset Package Name, Te ⁇ itory, and
  • the Query license module 1768 orders the licenses by Agreement LD.
  • Step 5 The Auditor ends the transaction. This use case has a number of extensions:
  • the Query license module 1768 displays the package name, whether the package is a cross-license package, and the Limitations field in a list ordered by name, ff the Auditor selects a package, the Query license module 1768 extends the use case with the Modify ff Asset Package use case.
  • the Query license module 1768 displays the territory's Abbreviation, Full Name, and Description in a list ordered by Abbreviation.
  • the Auditor cannot change territories here but must instead use the Modify License Agreement use case.
  • the Query license module 1768 displays the field-of-use Display Name and Description in a list ordered by name.
  • the Auditor cannot change territories here but must instead use the Modify License Agreement use case.
  • ° ff the license agreement has any parties, the Query license module
  • the Query license module 1768 displays the entity name and role name of the parties in a list ordered by role name and entity name, ff the Auditor selects a party, the Query license module 1768 extends this use case with the Modify Entity use case.
  • the Query license module 1768 displays the term number, term type, and description in a list ordered by term number, ff the Auditor selects a term, the Query license module 1768 extends this use case with the Modify Compensation Term use case.
  • the Query license module 1768 displays the royalty statement reporting period in a list ordered by period, ff the Auditor selects a statement, the Query license module 1768 extends this use case with the Modify Royalty Statement use case.
  • the Query license module 1768 displays the two Infr Based Agreement fields Infringement Release Granted and Infringement Comment. ° ff the Auditor selects a queried license agreement row, the Query license module 1768 extends the use case with the Modify License Agreement use case.
  • the modify license agreement use case 8202 is diagramed in FIG. 82.
  • the Data Entry Clerk modifies a license agreement in the Licensing database 1204. Modifying the agreement entails entering/revising structured data (name, description, effective date, and so on).
  • the Data Entry Clerk can edit or add new compensation terms that describe the fee and royalty structure of the agreement.
  • the Data Entry Clerk can revise the links between the agreement and the set of asset packages representing the licensed ff assets.
  • the Data Entry Clerk can revise the links between the agreement and the set of entity roles that identify the various parties to the agreement (licensor, licensees, attorneys, and so on). This use case is further described below.
  • Step 1 The License Administrator begins the transaction.
  • Step 2. The Modify license agreement module 1758 displays the License Agreements in the Licensing Database.
  • Step 3. The License Administrator chooses a license agreement to modify.
  • Step 4 If the License Administrator has write permission on the selected document, the Modify license agreement module 1758 displays the license agreement in a data entry form such as that used in the Enter License Agreement use case and shows the current values of all fields. See FIG. 69. Step 5.
  • the License Administrator modifies any of the structured fields and linked objects of the license agreement in any order: Step 5.1.
  • the License Administrator modifies the structured fields of the agreement: the Agreement LD, the Name, Description, Effective Date, Expiration Date, Exclusivity, Assignable, Transferable, Revocable, Confidential, and Terminated.
  • Step 5.2 The License Administrator modifies the structured fields of the license agreement: Perpetual, Infringement Based (see Extensions), Can Sublicense, Annual Audit, Audit at Licensee Expense, Favored Nation, Improvements, Grant Back, and Withholding Percentage.
  • Step 5.3 The License Administrator uses the Link to Asset Packages use case to modify the set of asset packages for the license.
  • Step 5.4 The License Administrator uses the Enter
  • Compensation Term use case to create the compensation terms for the license This step can be repeated.
  • Step 5.5 The License Administrator uses the Remove Compensation Term use case to remove any unwanted compensation terms from the license to the Recycle Bin. This step can be repeated.
  • Step 5.6 The License Administrator uses the Link to Party use case to modify the set of parties to the agreement.
  • Required parties include one licensor and at least one licensee. You can also add other parties such as attorneys and other roles entered through the Add Role use case by the System Administrator. This step can be repeated.
  • Step5.7 The License Administrator selects a different Security
  • Step 6. The License Administrator commits the transaction.
  • Step 7. The Modify license agreement module 1758 updates the Agreement
  • This use case has a number of extensions: ° ff the asset package or packages the License Administrator wants to add do not exist, extend the use case with the Create ff Asset Package use case to create the appropriate package(s).
  • the remove license agreement use case 8302 is diagramed in FIG. 83.
  • This is preferably an administrator use case.
  • the license system Administrator removes a license agreement and its related data from the Licensing Database 1204, including infringement information, compensation terms, expected revenue, royalty statements, party links, asset package links, territorial restrictions, and field-of-use restrictions. The operation of this use case is described below.
  • Step 1 The License system Administrator begins the transaction.
  • Step 2. The Remove license agreement module 1705 displays a list of all the licenses in the Licensing Database, displaying the document LD, the Agreement LD, and the Name.
  • Step 3. The License system Administrator selects one or more license agreements and removes them.
  • Step 4. The Remove license agreement module 1705 uses the Remove
  • Step 5 The Remove license agreement module 1705 deletes the information from the Licensing database 1204 and moves it to the Recycle Bin (implementation may differ regarding deferring the actual SQL deletes, and there is no notification of commit to the License system Administrator).
  • This use case has a number of extensions:
  • the administrator can restore the removed License Agreement and its related information.
  • the print license use case 8402 is diagramed in FIG. 84.
  • This use case extends the Print Object use case.
  • the System prints a License Agreement, including all information in the Licensing Database 1204 about the agreement, its parties, its compensation terms, its asset packages (with territorial and field-of-use restrictions), its royalty statements, and the expected revenue and payments received to date. The operation of this use case is further described below.
  • Step 1 The Actor in the Print Object use case selects a License Agreement and prints it.
  • Step 2. The Print license module 1712 prints a formatted report with the
  • the Print license module 1712 prints the parties to the agreement, with name, organization, and primary contact information.
  • the Print license module 1712 prints the compensation terms of the agreement, printing the Term Number, Term Type, and the Description of each term along with the cu ⁇ ency symbol and the Amount and any Due Date for the term.
  • the Print license module 1712 prints the Asset Packages for the license using the Print Asset Package use case. Step ⁇ .
  • the Print license module 1712 prints the Royalty Statements received for the license using the Print Royalty Statement use case. Step 7.
  • the Print license module 1712 prints the Expected Revenues and the Payments linked to them, printing the Payment Number, Amount, and Due Date for each Revenue and the Payment LD, Receipt Date, Cu ⁇ ency Unit Symbol, and Amount Allocated for each Payment.
  • the administer te ⁇ itories use case 8502 is diagramed in FIG. 85.
  • This is preferably an administrator use case.
  • the system Administrator creates, modifies, and or removes te ⁇ itories from the Licensing Database 1204.
  • the system comes preinstalled with the te ⁇ itories Worldwide, USA, Japan, and EU. The operation of this use case is further described below.
  • Step 1 The System Administrator starts the transaction.
  • Step 2. The Administer te ⁇ itories module 1709 displays a list of Territories, displaying the Territory LD, Abbreviation (such as EUSA), Full Name (such as East Coast of the United States of America), and Description (such as "the region including all eastern states of the United States of America").
  • Step 3 The System Administer takes one of the following actions:
  • Step 3.1 The System Administrator creates a new Te ⁇ itory, entering the Abbreviation, Full Name, and Description (the Administer territories module 1709 generates the Te ⁇ itory LD).
  • Step 3.2 The System Administrator selects one of the cu ⁇ ent
  • Step 3.3 The System Administrator selects one of the cu ⁇ ent
  • Step 3.4 The System Administrator selects one of the current Territories and removes it.
  • Step 4. The System Administrator ends the transaction.
  • Step 5. The Administer territories module 1709 commits the changes in the Licensing Database 1204.
  • the Administer te ⁇ itories module 1709 confirms the commit to the System Administrator.
  • This use case has a number of extensions: ° ff the System Administrator presses FI or the equivalent, the application extends the use case with the Display Help use case.
  • the Administer te ⁇ itories module 1709 deletes the information from the Licensing database 1204 and moves it to the Recycle Bin (implementation may differ regarding deferring the actual SQL deletes, and there is no notification of commit to the System Administrator).
  • the Administer te ⁇ itories module 1709 confirms the commit to the System Administrator. At any time until clearing the Recycle Bin, the administrator can restore the removed Te ⁇ itory and its related information.
  • the administer fields of use case 8602 is diagramed in FIG. 86.
  • This is preferably an administrator use case.
  • the system Administrator creates, modifies, and/or removes fields of use from the Licensing Database 1204. The operation of this use case is further described below.
  • Step 1. The System Administrator starts the transaction.
  • Step 2. The Administer fields of use module 1711 displays a list of Fields of
  • Step 3 The System Administer takes any of the following actions:
  • Step 3.1 The System Administrator creates a new Field of Use, entering the Display Name and Description (the Administer fields of use module 1711 generates the Field of Use LD).
  • Step 3.2 The System Administrator selects one of the cu ⁇ ent
  • Step 3.3 The System Administrator selects one of the cu ⁇ ent
  • Step 3.4 The System Administrator selects one of the cu ⁇ ent
  • Step 4. The System Administrator ends the transaction.
  • Step 5. The Administer fields of use module 1711 commits the changes in the Licensing Database 1204.
  • the Administer fields of use module 1711 confirms the commit to the System Administrator.
  • the Administer fields of use module 1711 deletes the information from the Licensing database 1204 and moves it to the Recycle
  • the Administer fields of use module 1711 confirms the commit to the System Administrator. At any time until clearing the Recycle Bin, the administrator can restore the removed Field of Use and its related information.
  • the display license agreements use case 15302 is diagramed in FIG. 153.
  • This use case displays a table of license agreements with the basic data for each agreement.
  • the Actor may select one or more agreements and conduct further operations such as Modify License Agreement. The operation of this use case is further described below.
  • Step 1 The Actor starts the transaction.
  • the display license agreements module 15304 displays a table of all the License Agreements to which the Actor has read access. Each row of the table corresponds to a License Agreement.
  • the columns include the License Agreement LD, the Name, the Description, the Effective Date, the Expiration Date, the Withholding Percentage, and a series of checkbox items: Exclusivity, Assignable, Transferable,
  • Step 3 The Actor ends the transaction. This use case has a number of extensions:
  • the display license agreements module 15304 displays the new license and its fields in the table.
  • the Modify License Agreement use case extends this one in a separate transaction.
  • the Actor selects a license agreement from the table and initiates the extending use case.
  • the saved changes from the extending use case appear in the table when that use case ends.
  • ° ff the Actor wants to print a license agreement
  • the Print License use case extends this one.
  • the Actor selects one or more license agreements from the table and initiates the extending use case.
  • the Remove License Agreement use case extends this one.
  • the Actor selects one or more license agreement from the table and initiates the extending use case.
  • the display license agreements module 15304 removes the selected license or licenses from the table.
  • the enter adjustment use case 15702 is diagramed in FIG. 157.
  • the Enter License Agreement and Modify License Agreement use cases use this one to enter adjustments to compensation terms in a license agreement in the Licensing Database 1204.
  • the Licensing Administrator or Data Entry Clerk creates an adjustment with the details appropriate to the particular kind of adjustment. Adjustments have a description, an amount, a cu ⁇ ency, and a due date. A minimum guarantee also has a time period and possible escalations. An advance may be refundable or not.
  • the adjustments modify the revenue stream that compensation terms generate, and the Link Adjustment to Terms use case relates an adjustment to the terms that generate the revenue that it adjusts.
  • a license agreement structures its revenue stream based on a combination of fees and royalty payments (and possibly some other kinds of compensation).
  • the agreement also contains terms that affect the revenue from these terms, the minimum guarantee and the advance.
  • a minimum guarantee is an amount of money that the licensor must receive by the end of the guarantee period, usually one year but sometimes quarterly or some other period. If the revenue from certain compensation terms does not add up to this amount, the licensee must make up the difference.
  • An advance is an amount paid to the licensor by the licensee in advance of revenue (usually royalties). The licensee then subtracts the advance amount from the compensation due until the entire amount of the advance is accounted for. From that point on, the licensee then begins payments to the licensor.
  • Any given adjustment may cover any number of different compensation terms for the same license. For example, an advance may cover an initial fee and a series of royalty payments. A minimum guarantee could cover two or three different royalty terms but not a maintenance fee.
  • Step 1 The using use case passes in the object identifier for the license agreement to which the Data Entry Clerk or License Administrator (the Actor) wants to add adjustments.
  • Step 2 The enter adjustment module 15702 displays a list of the cu ⁇ ent set of adjustments for this license in preferably order of term number, displaying the
  • Step 3 The Actor creates a new adjustment and selects one of the term types (Minimum Guarantee or Advance).
  • Step 4. The enter adjustment module 15702 displays the adjustment with default values (Amount 0, Cu ⁇ ency from the last term or the default cu ⁇ ency for the system, and Due_Date empty). It displays a form for the term given the default term type (see Extensions).
  • Step 5 The Actor enters the standard details for the adjustment and the details for the particular term type (see Extensions), then either repeats from step 3 or ends the use case.
  • Step 6 The enter adjustment module 15702 inserts the new terms into the Licensing Database 1204.
  • This use case has a number of extensions. ° ff the Actor presses FI or the equivalent, the application extends the use case with the Display Help use case.
  • Recu ⁇ ing Time Period use case to enter a Recurring Period (see below) or enters a Single Date.
  • the Actor enters a table for an escalation schedule (an Open Ended Period and an Amount for each row of the table) .
  • the enter adj ustment module
  • the enter adjustment module 15702 displays a field for entering a Single Date representing the due date of the advance and a field for the Refundable flag. The enter adjustment module 15702 inserts these into the Advance table.
  • the enter adjustment module 15702 displays the Time Unit, the Start Date, the Recu ⁇ ence Rate, the Starting Interval, the Interval Unit, and the choice of ending the cycle with a specific number of recu ⁇ ences (Count Limited Recu ⁇ ing Period) or a specific End Date (Date Limited Recu ⁇ ing Period).
  • the modify adjustment use case 16102 is diagramed in FIG. 161.
  • the Modify License Agreement use case uses this one to change existing adjustments that belong to a license agreement in the Licensing Database 1204.
  • the Licensing Administrator selects a particular adjustment and modifies its attributes.
  • the Licensing Administrator also modifies the links between adjustments and compensation terms for the license agreement in the Link Adjustment to Terms use case. See the Enter Adjustment use case for background material on adjustments.
  • Step 1 The using use case passes in the object identifier for the license agreement in which the License Administrator wants to change adjustments.
  • Step 2 The modify adjustment module 16104 displays a list of the cu ⁇ ent set of adjustments for this license in order of term number, displaying the term
  • Step 3 The License Administrator selects an adjustment for modification.
  • Step 4 The modify adjustment module 16104 displays the cu ⁇ ent values for the selected adjustment through a data entry form for the adjustment, including due date, cu ⁇ ency, amount, or description.
  • Step 5 The License Administrator changes any of these values, then ends the use case.
  • Step 6. The modify adjustment module 16104 updates the adjustment in the Licensing Database 1204.
  • the modify adjustment module 16104 displays fields for entering a Recurring Period (see below) and a table for an escalation schedule (an Open Ended Period and an Amount). The License Administrator may add or remove intervals from the escalation schedule or may change the amount or start date for an existing interval.
  • ° ff the Term Type is Advance, the modify adjustment module 16104 displays the Due Date of the advance and the Refundable flag.
  • the modify adjustment module 16104 displays the Time Unit, the Start Date, the Recu ⁇ ence Rate, the
  • the link to adjustment use case 16202 is diagramed in FIG. 162. According to this use case, a License Administrator selects one or more adjustments from a list. The link to adjustment module 16202 creates a link between the input compensation term and the selected adjustments. It will be illustrative to consider selected background items. The invention allows one to adjust the revenue stream from a compensation term through advances or minimum guarantees. These are adjustment objects that are part of the license.
  • the advance is a payment from the licensee to the licensor in anticipation of revenue from the license.
  • the amount from the compensation terms covered by the advance is reduced by the amount of the advance until the revenue accounts for the entire advance.
  • the minimum guarantee is a floor for revenue during a specific period, usually a year, ff the revenue for that period does not come up to the guaranteed amount, the difference becomes due as a separate payment.
  • Step 1 The License Administrator starts the use case with an open transaction containing a compensation term that will link to the adjustments.
  • the extended use case supplies the object identifier for the agreement.
  • Step 2 The link to adjustment module 16204 displays the types and descriptions of the adjustments for the license that owns the compensation term in a list ordered by adjustment number within the license, displaying any existing links.
  • Step 3 The License Administrator selects one or more adjustments from the list.
  • Step 4 The adjustment module 16204 creates and displays a link for each adj ustment the License Administrator selects .
  • Step 5 The Licensing Database 1204 links the adjustments to the compensation term through the Term_Adj ustment association table.
  • This use case has a number of extensions. °
  • the License Administrator can cancel the use case at any time. The result will be that the compensation term is unchanged from its status before using the use case.
  • the application extends the use case with the Display Help use case.
  • the remove compensation adjustment use case 16302 is diagramed in FIG. 163.
  • the Modify License Agreement use case uses this one to remove existing compensation adjustments that belong to a license agreement in the Licensing Database 1204. The operation of this use case is further described below.
  • Step 1 The using use case passes in the object identifier for the license agreement in which the License Administrator wants to change compensation adjustments.
  • Step 2 The remove compensation adjustment module 16304 displays a list of the cu ⁇ ent set of compensation adjustments for this license in order of adjustment number, displaying the term Description and the Adjustment Type.
  • Step 3 The License Administrator selects an adjustment to remove. In an embodiment, the adjustment cannot link to any compensation terms of the license.
  • Step 4 The remove compensation adjustment module 16304 deletes the information from the Licensing Database 1204 and moves it to the Recycle Bin.
  • the remove compensation adjustment module 16304 refuses to remove the compensation adjustment and instead displays an error message, "Cannot remove this compensation adjustment because there are links to compensation terms of this license.” Royalty Statements Use Cases
  • a royalty statement is a document that a licensee submits to a licensor to specify the licensed royalties owed for a given royalty period.
  • a royalty statement includes a number of royalty statement details. Each royalty statement detail lists a product, a number of units sold, an amount of revenue, and a calculated royalty amount.
  • the Royalty Statements View 8702 contains two panes, a license agreement spreadsheet 8704 and a royalty statement spreadsheet 8706.
  • FIG. 87A The agreement pane 8704 lets you select a license, and the royalty statement pane 8706 displays the royalty statements for that license. You add and modify statements by double-clicking on a blank row or an existing row, as with all the other views.
  • the enter royalty statement use case 8701 is diagramed in FIG. 87B.
  • the Data Entry Clerk queries a license, then enters information about a royalty statement that applies to that license into the database, then enters a series of detail items, one for each product detail on the royalty statement.
  • the new document has the classifier the Data Entry Clerk sets for it. The operation of this use case is further described below.
  • Step 1 The Data Entry Clerk begins the transaction to enter a new royalty statement.
  • the royalty statement view 8702 (FIG. 87 A) is displayed.
  • Step 2 The Data Entry Clerk uses the Query License use case to identify and select the license to which the new royalty statement applies. Alternatively, the Data Entry Clerk can select a license in the license agreement pane 8704 of the royalty statement view 8702. Step 3.
  • the Enter royalty statement module 1770 creates an object identifier for the new royalty statement that it uses to relate the statement to the queried license agreement and to the statement details. It then links the royalty statement to the queried license.
  • a royalty statement dialog 8802 (FIG. 88) is displayed.
  • the royalty statement dialog 8802 has a general tab 8804 and a details tab 8806.
  • the Data Entry Clerk enters the Fixed Time Interval for the reporting/statement period (Start Date and End Date) .
  • the Data Entry Clerk enters the royalty statement due date, receipt date, and (optionally) an investigation window date and a licensor invoice number.
  • the Data Entry Clerk optionally sets a security classification from a list of available Write classifications from the IPAM Security Subsystem 1602, to indicate the persons who have access to this royalty statement record.
  • Step 5 In the details tab 8806 (see FIG. 89), for each detail item on the royalty statement, the Data Entry Clerk creates a new detail for the royalty statement record by pressing the Add Detail button 8904. This results in displaying a detail dialog 9002.
  • the Data Entry Clerk enters the product (selecting from a list of products associated with the licensee), the number of units sold of the product, the revenue received from the sale and the cu ⁇ ency unit for the revenue, and the royalty due for the product, where this information is obtained from the royalty statement provided by the licensee. All details for the royalty statement are listed in a details area 8902 (FIG. 89).
  • Step 6 The Data Entry Clerk commits the transaction.
  • Step 7 The Enter royalty statement module 1770 inserts the Royalty
  • the Enter royalty statement module 1770 requests the IPAM Security System 1602 to set the document classification.
  • the enter royalty statement module 1770 confirms the commit to the
  • the modify royalty statement use case 9102 is diagramed in FIG. 91.
  • the License Administrator queries a license, then modifies any of the attributes of any of the linked royalty statements, and/or modifies any of the statement details, one for each product detail on the statement.
  • the operation of this use case is further described below.
  • Step 1 The License Administrator begins the transaction.
  • Step 2 The Modify royalty statement module 1766 displays the licenses to which the License Administrator has read access, displaying the object identifier, the Agreement LD, the Name, and the Description, in a form similar to that shown in FIG.
  • Step 3 The License Administrator selects a license from the license pane 8704.
  • Step 4 The Modify royalty statement module 1766 displays a list of existing royalty statements attached to the license in the royalty statement pane 8706.
  • Modify royalty statement module 1766 displays only those royalty statements to which the License Administrator has Read access.
  • Step 5 The License Administrator selects a royalty statement for modification from the royalty statement pane 8706. Step 6. ff the License Administrator has Write access to the royalty statement, the Modify royalty statement module 1766 displays the cu ⁇ ent field values in a form similar to that shown in FIG. 88.
  • Step 7 The License Administrator may modify the royalty statement Invoice Number, Due Date, Receipt Date, or the Investigation Window Date in any order.
  • Step 8. If the details tab 8806 is selected, the Modify royalty statement module 1766 displays the details for the selected royalty statement, displaying the product, the Units Sold, the Cu ⁇ ency, and the Revenue.
  • Step 9. For each detail item on the royalty statement, the License Administrator can modify the name of the product, the number of units sold, or the revenue received and its cu ⁇ ency unit, in any order.
  • Step 10 The License Administrator commits the transaction.
  • Step 11 The Modify royalty statement module 1766 updates the royalty statement.
  • Step 13 For each detail modified, the Modify royalty statement module 1766 updates the detail.
  • Step 14 The Modify royalty statement module 1766 confirms the commit to the License Administrator.
  • the Modify royalty statement module 1766 changes the License LD in the Royalty Statement.
  • the query statement use case 9202 is diagramed in FIG.92.
  • the Auditor enters search criteria for the statement, and the Query statement module 1772 displays the statement from the Licensing Database 1204.
  • the Auditor can select a statement to see the statement details, and he or she can select a detail to see any payment allocations for the detail. The operation of this use case is further described below.
  • Step 1 The Auditor starts the transaction.
  • Step 2 The Query statement module 1772 displays the licenses to which the Auditor has read access, displaying the object identifier, the Agreement LD, the Name, and the Description in a format similar to that shown in FIG. 87 A.
  • Step 3 The Auditor selects a license for query of statements.
  • Step 4 The Query statement module 1772 displays a query form that lets the Auditor enter selection conditions on the set of statements, including object identifier, the reporting period Start and End Dates, the Invoice Number, the Due Date, the
  • Step 5 The Auditor enters query criteria and starts the query.
  • the Query statement module 1772 displays the royalty statements for the license in preferably reverse chronological order to which the Auditor has Read access, displaying the object identifier, the reporting period Start and End Dates, the
  • Step 7 The Auditor selects a statement.
  • Step 8 The Query statement module 1772 queries all the details of the selected royalty statement from the Licensing Database 1204 and displays them, if any, showing the Product, the Units Sold, the Revenue and its cu ⁇ ency unit symbol, and the Royalty Due, in a form similar to that shown in FIG. 89.
  • Step 9 The Auditor selects a detail.
  • the Query statement module 1772 queries all the payment detail allocations from the Licensing Database 1204 and displays the Amount Allocated for each one with a label that allows the Auditor to see it, if any.
  • the Query statement module 1772 displays the Amount Allocated in the cu ⁇ ency of the detail, converting it if the cu ⁇ ency of the payment is different from the detail cu ⁇ ency unit using the Convert Cu ⁇ ency use case.
  • the Query statement module 1772 lists the allocations in preferably Receipt Date order. Step 11.
  • the Auditor ends the transaction.
  • the remove royalty statement use case 9302 is diagramed in FIG. 93.
  • this is an administrator use case.
  • the system Administrator removes a linked royalty statement, which removes the statement details as well, all from the Licensing Database 1204. This operation is available only through the System Administrator interface to limit the potential for accidental removal of the data. The operation of this use case is further described below.
  • Step 1. The System Administrator begins the transaction.
  • Step 2. The Remove royalty statement module 1707 displays a list of existing royalty statements.
  • Step 3 The System Administrator selects one or more royalty statements and removes them.
  • Step 4 The Remove royalty statement module 1707 deletes the information from the licensing database 1204 moves it to the Recycle Bin (implementation may differ regarding details on defe ⁇ ing the actual SQL deletes, and there is no notification of commit to the System Administrator).
  • This use case has a number of extensions:
  • the print statement use case 9402 is diagramed in FIG. 94. This use case extends the Print Object use case, and the Print License use case uses it.
  • the Query statement module 1772 prints a Royalty Statement, including all information in the
  • Licensing Database 1204 about the statement, its details, and the allocation of payments to those details. This use case is further described below.
  • Step 1 The Actor in the Print Object use case or the Print License Use case selects a Royalty Statement and prints it.
  • the Print statement module 1714 prints a formatted report with the Start Date, End Date, Agreement Name, Agreement LD, any Invoice Number, the Due Date, the Receipt Date, and or the Investigation Window Date.
  • the Print statement module 1714 prints the Royalty Statement Details for the statement. Each detail contains the Product Name, Product Description, Units Sold, Revenue, Cu ⁇ ency Unit Symbol, and/or Royalty Due.
  • Step 4 the Print statement module 1714 prints any payment allocations, printing the Payment LD, the Receipt Date, any Invoice Number, the
  • the display royalty statements use case 15802 is diagramed in FIG. 158.
  • This use case displays a table of licenses and a table of royalty statements with the basic data for each agreement and statement within the agreement.
  • the Actor may select an agreement.
  • the display royalty statements module 15804 then displays all the royalty statements to which the Actor has read access that belong to the selected license agreement.
  • the Actor may then select one or more statements within the agreement.
  • Step 1 The Actor starts the transaction.
  • Step 2 The display royalty statements module 15804 displays a table of all the License Agreements to which the Actor has read access using the Display License Agreements use case. Step 3. The Actor selects a single license agreement from that table.
  • the display royalty statements module 15804 displays a table of all the Royalty Statements from the Licensing Database 1204 to which the Actor has read access. Each row of the table co ⁇ esponds to a single Royalty Statement. The columns include the Reporting Period's Start Date and End Date, the Invoice Number, the Due Date, the Receipt Date, and the Investigation Window Date.
  • Step 5 The Actor ends the transaction.
  • the Modify Royalty Statement use case extends this one in a separate transaction.
  • the Actor selects a statement from the table and initiates the extending use case.
  • the saved changes from the extending use case appear in the statement table when that use case ends.
  • ° ff the Actor wants to print a royalty statement the Print Statement use case extends this one.
  • the Actor selects one or more royalty statements from the table and initiates the extending use case.
  • the Remove Royalty Statement use case extends this one.
  • the Actor selects one or more royalty statements from the table and initiates the extending use case.
  • the display royalty statements module
  • the query statement use case 15502 is diagramed in FIG. 155.
  • the Auditor enters search criteria for the statement, and the query statement module 15504 displays the statement from the Licensing Database 1204.
  • the Auditor can select a statement to see the statement details, and he or she can select a detail to see any payment allocations for the detail. The operation of this use case is further described below.
  • Step 1 The Auditor starts the transaction.
  • Step 2 The query statement module 15504 displays the licenses using the Display Licenses use case.
  • Step 3 The Auditor selects a license for query.
  • Step 4 The query statement module 15504 displays a form that lets the Auditor enter any combination of the reporting period Start and End Dates, the Invoice Number, the Due Date, the Receipt Date, and the Investigation Window Date.
  • Step 5 The Auditor enters values into the query form fields and starts the query.
  • Step 6 The query statement module 15504 combines the entries into a complete query expression, executes the query in the Licensing Database 1204, then displays the resulting statements in the system that satisfy the query conditions to which the Auditor has read access, ordered by start date.
  • Step 7. The Auditor selects a statement.
  • Step 8 The query statement module 15504 queries all the details of the selected royalty statement from the Licensing Database 1204 and displays them in order of Line Number, if any, showing the Product, the Units Sold, the Revenue and its cu ⁇ ency unit symbol, and the Royalty Due. Step 9. The Auditor selects a detail.
  • the query statement module 15504 queries all the payment detail allocations from the Licensing Database 1204 and displays the Amount Allocated for each one with a label that allows the Auditor to see it, if any.
  • the query statement module 15504 displays the Amount Allocated in the cu ⁇ ency of the detail, converting -no-
  • the query statement module 15504 lists the allocations in preferably Receipt Date order.
  • Step 11 The Auditor ends the transaction.
  • the Payments View 9502 contains two panes, a license agreement spreadsheet 9504 and a payment spreadsheet 9506.
  • the agreement pane 9504 lets you select a license, and the payment pane 9506 displays the payments for that license. You add and modify payments by double-clicking on a blank row or as existing row, as with all the other views.
  • the payment use case 10002 is diagramed in FIG. 100.
  • the Data Entry Clerk records the details of a payment related to a license in the Licensing Database 1204. The operation of this use case is further described below.
  • Step 1 The Data Entry Clerk starts the transaction to enter a new payment.
  • Step 2. The Enter payment module 1774 displays a list of licenses in the license pane 9504 of the payments view 9502.
  • Step 3 The Data Entry Clerk selects a license in the license pane 9504 of the payments view 9502.
  • Step 4 The Enter payment module 1774 displays a list of payments for the license in the payments pane 9506. Step 5.
  • the Data Entry Clerk signals the desire to add a new payment for the selected license using any procedure described herein.
  • the Enter payment module 1774 displays a form 9602 (FIG. 96) for entering the details of a payment and creates a new object identifier for the payment object and a link from that payment to the selected license.
  • the form 9602 includes a general tab 9604, a royalty statement details tab 9606, and an expected revenue tab
  • Step 7 the Data Entry Clerk enters the Receipt Date, the Amount received, and the Cu ⁇ ency in any order.
  • the Data Entry Clerk enters a withheld amount (the part of the total amount of the payment that represents a foreign company's withholding of tax due on the payment), an invoice number (for an invoice needed to release the payment from a foreign tax authority), and any late payment interest amount (part of the total amount of the payment that is a penalty for late payment based on the interest rate in the license agreement), again in any order.
  • the Data Entry Clerk selects a Security Class for the payment.
  • the Data Entry Clerk commits the transaction. Data is not typically entered into the royalty statement details tab 9606 and the expected revenue tab 9608, although these tabs are active and accessible according to an embodiment of the invention.
  • Step 8 The Enter payment module 1774 creates a persistent payment and a link to the indicated license.
  • the Enter payment module 1774 confirms the committed transaction to the Data Entry Clerk.
  • the modify payment use case 10102 is diagramed in FIG. 101.
  • the License Administrator modifies the details of a payment related to a license.
  • the License Administrator then optionally links the licensee's payment to the expected revenue estimates of the license, to the details of a royalty statement, and to the general ledger debit and credit entries.
  • the operation of this use case is further described below.
  • Step 1 The License Administrator starts the transaction.
  • Step 2. The Modify payment module 1776displays using the payments view
  • Step 3 The License Administrator selects a license listed in the license agreement pane 9504.
  • Step 4 The Modify payment module 1776 displays in the payments pane
  • Step 5 The License Administrator selects a payment from the payments pane 9506.
  • a form 9602 FIG. 96
  • Step 7 The License Administrator optionally modifies any of the fields except for the object identifier and commits the transaction.
  • Step 8 The Modify payment module 1776 updates the payment in the Licensing Database 1204.
  • the Modify payment module 1776 confirms the committed transaction to the Licensing Administrator.
  • the business is linking payments to expected license revenue estimates
  • the License Administrator uses the Link to Expected Revenue use case to link the payment to the estimates.
  • the license and payment object identifiers for the selected license and payment pass into the used use case.
  • the used use case creates or removes any links in the Licensing Database.
  • the business is linking payments to royalty statement details
  • the License Administrator uses the Link to Detail use case to link the payment to the details of one or more royalty statement details.
  • the license and payment object identifiers for the selected license and payment pass into the used use case.
  • the used use case creates or removes any links in the Licensing Database.
  • the License Administrator enters two General Ledger Entry items , supplying a GL Account Number from a list of valid numbers, an Amount, and an Entry Date (the date on which the GL recorded the payment) for each entry.
  • the License Administrator chooses whether each entry is a debit or a credit entry. (These entries should usually be supplied by the accounting department, which then sends the records on to the licensing department for allocation purposes.
  • the GL feature is optional and configurable.
  • the application extends the use case with the Display Help use case.
  • the link to expected revenue use case 10202 is diagramed in FIG. 102.
  • a License Administrator allocates a payment to the expected revenue estimates deriving from the license compensation terms.
  • the link to expected revenue use case 10202 creates a series of links to these estimates in the Licensing Database 1204. Via these links, it is possible to compare estimated license revenue to actual license revenue/payments.
  • the operation of this use case is further described below. Step 1.
  • the License Administrator initiates the use case from the calling use case, passing in an object identifier for a payment and an object identifier for a license agreement to which the payment applies.
  • Step 2 The Link to expected revenue module 1778 displays in an estimate pane 9808 of the expected revenue tab 9608 (FIGS .98 and 99) the Expected Amount,
  • Step 3 The License Administrator selects an estimate and enters an allocation amount for it. This can be done by entering an amount in field 9802, or a percentage of the total payment in field 9804. The total payment amount is displayed in field 9806. This step repeats, as necessary.
  • Step 4 The Link to expected revenue module 1778 stores an allocation amount into the Licensing Database 1204 for each non-zero allocation entered in step 3.
  • the Link to expected revenue module 1778 displays the e ⁇ or message "Sum of allocations must be less than or equal to total payment" and clears the entered allocation.
  • the Link to expected revenue module 1778 displays the e ⁇ or message "You must enter a positive allocation for each revenue estimate you select” and puts the focus on the first nonpositive amount in the list. ° The cu ⁇ ency unit of the payment should match the cu ⁇ ency unit of the expected revenue estimate, ff not, the Link to expected revenue module 1778 displays a warning message ("Converting cu ⁇ encies from %s to %s") that the amounts are in different cu ⁇ encies and offers the user the chance to use the Convert Cu ⁇ ency use case to convert one cu ⁇ ency to the other. The link to expected revenue module 1778 displays both the amounts in each allocation link.
  • the application extends the use case with the Display Help use case.
  • the link to detail use case 10302 is diagramed in FIG. 103.
  • This use case extends the Modify Payment use case. While modifying a payment, the License
  • the use case links the selected details to the payment, allocating part of the payment to each of the details. The operation of this use case is further described below.
  • Step 1 The License Administrator initiates the use case from the calling use case, passing in an object identifier for a payment and an object identifier for a license agreement to which the payment applies.
  • Step 2 The Link to detail module 1780 displays the royalty statements for the license in the royalty statement details tab 9606 (FIG.96).
  • FIG.97 there are two royalty statements 9710 and 9712 displayed.
  • Royalty statement 9710 has two details 9714
  • royalty statement 9712 has two details 9716.
  • more complete information is displayed for each detail at this point. Such information may include the line number, product name, units sold, revenue amount, royalty due with cu ⁇ ency symbol, etc.
  • Step 3 The License Administrator selects a detail and enters an allocation amount. This can be done by entering an amount (such as in field 9704), or a percentage of the payment total (such as in field 9708). This step repeats as necessary. Step 4. The License Administrator signals completion.
  • Step 5 The Link to detail module 1780 creates links between the details and the payment. This use case includes a number of extensions:
  • the Link to detail module 1780 displays the e ⁇ or message "Sum of allocations must be less than or equal to total payment" and clears the entered allocation.
  • the Link to detail module 1780 displays the e ⁇ or message "You must enter a positive allocation for each detail you select” and puts the focus on the first nonpositive amount in the list. ° The cu ⁇ ency unit of the payment should match the currency unit of the statement detail, ff not, the Link to detail module 1780 displays a warning message ("Converting cu ⁇ encies from %s to %s") that the amounts are in different cu ⁇ encies and offers the user the chance to use the Convert Cu ⁇ ency use case to convert one cu ⁇ ency to the other. The link to detail module 1780 displays both the amounts in each allocation link.
  • the application extends the use case with the Display Help use case.
  • the print payment use case 10402 is diagramed in FIG. 104. This use case extends the Print Object use case.
  • the print payment module 1716 prints a Payment, including all information in the Licensing Database 1204 about the payment, its
  • Step 1 The Actor in the Print Object use case selects a Payment and issues a command to print it.
  • the Print payment module 1716 prints a formatted report with the Payment LD, the Cu ⁇ ency Unit Symbol, the Amount, the Withheld Amount, the Late Payment Interest Amount, the Receipt Date, the Invoice Number, etc.
  • Step 3 The Print payment module 1716 prints the General Ledger Entries, printing the GL Account Number, the Account Description, the Amount, the Entry
  • the Print payment module 1716 prints the allocations of the payment to royalty statement details, including the Royalty Statement Start and End Dates, the Detail Line Number, the Product Name, the Detail Currency Unit Symbol, Detail Royalty Due, and the Amount Allocated.
  • the Print payment module 1716 prints the allocations of the payment to expected revenue, including the License Agreement LD and Name, the Term Number, the Expected Cu ⁇ ency Unit, the Expected Amount, the Expected Due Date, and the Amount Allocated.
  • the remove payment use case 10502 is diagramed in FIG. 105. This is preferably an administrator use case. According to this use case, the System
  • Step 1 The System Administrator begins the transaction.
  • Step 2 The Remove payment module 1713 displays a list of all the payments in the Licensing Database 1204, displaying the Payment LD, the Payor Name, the Receipt Date, and the Amount. Step 3.
  • the System Administrator selects one or more payments and removes them (that is, issues command(s) to remove them).
  • Step 4. The Remove payment module 1713 deletes the information from the Licensing database 1204 and moves it to the Recycle Bin (implementation may differ regarding deferring the actual SQL deletes, and there is no notification of commit to the System Administrator). This use case has a number of extensions:
  • the administrator can restore the removed Asset.
  • the query payment use case 10602 is diagramed in FIG. 106.
  • the Auditor queries payments based on payer, on licensees or licensors, on links to royalty statements or expected revenue, on General Ledger accounts, or on receipt date.
  • the Query payment module 1784 displays the payments, any links, and any GL entries. The operation of this use case is further described below.
  • Step 1 The Auditor starts the transaction.
  • the Query payment module 1784 displays the licenses to which the Auditor has read access, displaying the object identifier, the Agreement LD, the Name, and the Description. Step 3. The Auditor selects a license for query of payments.
  • the Query payment module 1784 displays a query form that lets the Auditor enter selection conditions on the set of payments, including object identifier, Payor Name, payment Receipt Date, Amount, Withheld Amount, Late Payment Interest Amount, and/or Invoice Number.
  • the Auditor enters query criteria and starts the query.
  • the Query payment module 1784 displays the payments for the license in preferably reverse chronological order to which the Auditor has Read access, displaying the object identifier, object identifier, Payor Name, payment Receipt Date, Amount, Withheld Amount, Late Payment Interest Amount, and/or Invoice Number.
  • Step 7. The Auditor selects a payment.
  • Step 8. The Query payment module 1784 displays a list of General Ledger entries, if any, showing the Entry Type, GL Account Number, Amount, Cu ⁇ ency Unit Symbol, and Entry Date. The Query payment module 1784 preferably orders the entries by GL Account Number.
  • Step 9 The Queiy payment module 1784 displays a list of Payment Detail Allocations, showing the Royalty Statement Start Date Time and Amount Allocated.
  • the Query payment module 1784 preferably orders the allocations by License Name, Start Date Time, and Line Number.
  • Step 10 The Query payment module 1784 displays a list of License
  • the Query payment module 1784 preferably orders the allocations by License OLD, Term
  • Step 11 The Auditor ends the transaction.
  • the maintain GL accounts use case 10702 is diagramed in FLG. 107. According to this use case, the License Administrator creates, updates, or removes accounts from the Licensing Database 1204. The operation of this use case is further described below.
  • Step 1 The License Administrator starts the transaction.
  • Step 2. The Maintain GL accounts module 1786 displays the list of cu ⁇ ent GL Accounts, displaying the Account Number and the Description.
  • Step 3 The License Administrator modifies the set of GL Accounts, performing any of the following actions on the set of accounts: Step 3.1.
  • the License Administrator creates a new GL Account, entering the Account Number and the Description.
  • Step 3.2 The License Administrator selects one of the cu ⁇ ent
  • Step 3.3 The License Administrator selects one of the cu ⁇ ent GL Accounts and removes it.
  • Step 4. The License Administrator ends the transaction.
  • Step 5. The Maintain GL accounts module 1786 commits the changes in the Licensing Database 1204.
  • the Maintain GL accounts module 1786 confirms the commit to the License Administrator.
  • ff a GL Account relates to any General Ledger Entries, on modifying the account number, the Maintain GL accounts module 1786 prompts the License Administrator whether to change the account number for the Entries or to cancel the transaction.
  • the link payment to entity use case 15102 is diagramed in FIG. 151.
  • This use case extends the Modify Payment use case to link or unlink the portion of a payment linked to a particular license to a specific set of named entities in the Licensing Database 1204.
  • the License Administrator allocates some portion of the portion of a payment to a specific named entity. It will be illustrate to consider the following scenario.
  • a licensor licenses packages of assets to licensees with a license agreement. The licensees use the assets to produce products that generate revenue. Depending on the license agreement compensation terms, the licensee pays various kinds of payments to the licensor: fees or royalties. These payments constitute a revenue stream to the licensor as a series of payments from the licensee.
  • a single payment may encompass more than one license, so the link between payment and license has a percent allocation that allocates a specific percentage of the payment to a particular license.
  • the licensor is usually an organization. Often, the licensor is not the business unit or person that ultimately "gets" or recognizes the revenue from a license for accounting purposes. That entity may be an organizational child of the licensor, but not necessarily, and there may be more than one entity that gets revenue from a license. A licensor therefore must have a way to allocate payment revenue from a particular license (a portion of a payment) to one or more named entities (people or organizations).
  • Step 1 The link payment to entity module 15104 passes in the object identifier for a license agreement and a payment (a License Payment link).
  • Step 2 The System displays the cu ⁇ ent set of links to entities from this license-payment link, displaying the name, description, and entity type for each linked entity.
  • Step 3 The License Administrator uses the Query Entities use case to display a list of entities.
  • the License Administrator selects a single named entity from the result of the query and links it to the license-payment link.
  • the Query Entity use case returns the object identifier for the entity to this use case.
  • Step 4 The link payment to entity module 15104 displays a form that lets the license administrator allocate a percentage of the license-payment amount to the entity. It displays a default value of 100% if there are no license payment allocations for this license-payment link or the difference between the sum of existing license payment allocations for this license-payment link and 100% .
  • Step 5. The link payment to entity module 15104 creates a link between the license-payment and the named entity, inserting a row in the License Payment Allocation table and displaying the new link in the displayed list of links.
  • Step 6 The License Administrator repeats steps 3-6 or ends the use case and returns to the extending use case.
  • the License Administrator wants to remove a given link, he or she selects it in the displayed list of links and tells the System to delete the link. The System then removes the link from the display and schedules the link for deletion from the database (the extending use case is running the transaction). The License Administrator can remove or add any number of links in this use case.
  • the display payments use case 15202 is diagramed in FIG. 152.
  • This use case displays a table of license agreements with the basic data for each agreement.
  • Actor may select one or more agreements and conduct further operations such as Modify License Agreement.
  • Modify License Agreement The operation of this use case is further described below:
  • Step 1 The Actor starts the transaction.
  • Step 2 The display payments module 15204 displays a table of all the License Agreements to which the Actor has read access using the Display License Agreements use case.
  • Step 3 The Actor selects a single license agreement from that table.
  • Step 4 The display payments module 15204 displays a table of all the Payments from the Licensing Database 1204 to which the Actor has read access. Each row of the table co ⁇ esponds to a single Payment. The columns include the Payor Name, the Cu ⁇ ency Unit Symbol, the Payment Amount, the Late Payment Interest
  • Step 5 The Actor ends the transaction.
  • the Enter Payment use case extends this one in a separate transaction.
  • the display payments module 15204 displays the new payment and its fields in the table.
  • Modify Payment use case extends this one in a separate transaction.
  • the Actor selects a payment from the table and initiates the extending use case.
  • the saved changes from the extending use case appear in the table when that use case ends. ° If the Actor wants to print a payment, the Print Payment use case extends this one.
  • the Actor selects one or more payments from the table and initiates the extending use case.
  • the Remove Payment use case extends this one.
  • the Actor selects one or more payments from the table and initiates the extending use case.
  • the display payments module 15204 removes the selected payment or payments from the table.
  • the invention supports time period related structures. For example, Royalties and Fees often have a recurring payment. For example, a royalty may be due at the end of every quarter, on every June 15, or something similar. Most license royalties and fees call for monthly, quarterly, or annual payments.
  • recu ⁇ ing periods may terminate in one of two ways.
  • a count-limited period has a certain number of periodic payments. For example, you could have a yearly fee due on June 15th for five payments.
  • a date-limited period goes to a certain end date: a royalty paid quarterly on the 15th of the second month of the quarter ending on February 15, 2015.
  • the beginning interval from the start date to the first recu ⁇ ing date may differ significantly in size from the other dates, as may the period from the last recu ⁇ ing date to an end date for a date-terminated period. For example, you may owe an annual fee every June 15th, with the sequence starting on June 1.
  • the first interval will be 15 days, while the second and onwards will be one year.
  • the enter recu ⁇ ing time period use case 15602 is diagramed in FIG. 156.
  • This use case is used by other use cases that must enter a recu ⁇ ing period of some kind into the Licensing Database 1204.
  • the use case permits the actor to enter the repetition structure for the recu ⁇ ing period. The operation of this use case is further described below.
  • Step 1 The enter recurring time period module 15602 displays a data entry form containing the Time Unit (default Year), the Repetition (default 1), and the
  • Step 2 The Actor chooses a Time Unit, a Repetition, and or a Recu ⁇ ing Period Type.
  • Step 3 The enter recurring time period module 15602 returns the appropriate object back to the using use case.
  • the enter recurring time period module 15602 sets the Time Period's Time Period Type field to 'R' to indicate a recurring period object.
  • This use case has a number of extensions.
  • the enter recu ⁇ ing time period module 15602 displays the Yearly options and allows the actor to choose between two sets of options: ° Specific Month and Specific Day: June 15th, November 2
  • the enter recu ⁇ ing time period module 15602 displays the Quarterly options and allows the actor to choose between three sets of options:
  • the enter recurring time period module 15602 displays the Monthly options and allows the actor to choose between two sets of options:
  • the enter recu ⁇ ing time period module 15602 displays the Weekly options and allows the actor to enter the day of the week: Tuesday ° ff Time Unit is Day, the enter recu ⁇ ing time period module 15602 displays nothing.
  • the enter recurring time period module 15602 displays the Number of Recu ⁇ ences. This controls the number of recurring dates within the whole period. ° If the actor sets the Recurring Period Type to Date Limited, the enter recurring time period module 15602 displays the End Date field. This controls the number of dates within the whole period by ending the whole period at a certain date. Modify Recurring Time Period
  • the modify recurring time period use case 16002 is diagramed in FIG. 160.
  • This use case is used by other use cases that must modify a recu ⁇ ing period of some kind in the Licensing Database 1204.
  • the use case permits the actor to modify the existing repetition structure for the recu ⁇ ing period or to change the type of period completely between the two concrete types (date-limited and count-limited). The operation of this use case is further described below.
  • Step 1 The actor passes in the object identifier for a time period to modify ( :TimePeriod_LD) .
  • Step 2. The modify recu ⁇ ing time period module 16004 displays a data entry form containing the Time Unit (default Year), the Repetition (default 1), and the Recu ⁇ ing Period Type (default Count Limited), all displaying the cu ⁇ ent values for the time period the actor passes in (:TimePeriod_LD) queried from the Licensing database 1204.
  • Step 3 The Actor changes the Time Unit, a Repetition, and/or the Recu ⁇ ing
  • Step 4 The modify recurring time period module 16004 returns the appropriate object back to the using use case.
  • This use case has a number of extensions.
  • ° ff the Recu ⁇ ing Period Type is Count Limited
  • the modify recurring time period module 16004 adds the Count_Limited_Recu ⁇ ing_Period table to the following SQL queries as the ⁇ concrete subclass> and displays the Number of Recu ⁇ ences. This controls the number of recu ⁇ ing dates within the whole period, ff the actor changes the Recurring Period Type to Date Limited, the modify recu ⁇ ing time period module 16004 changes to display the End Date field and deletes the count-limited row when the transaction completes, replacing it with a new Date Limited Recu ⁇ ins Period row.
  • the modify recu ⁇ ing time period module 16004 adds the DateJLimitedJR.ecu ⁇ ing_Period table to the following SQL queries as the ⁇ concrete subclass> and displays the End Date field. This controls the number of recurring dates within the whole period by ending the period at a certain date, ff the actor changes the Recu ⁇ ing Period Type to Count
  • the modify recu ⁇ ing time period module 16004 changes to display the Number of Recu ⁇ ences field and deletes the date-limited row when the transaction completes, replacing it with a new Count_Limited_Recurring_Period row.
  • the modify recurring time period module 16004 displays a set of options that the actor can use to control complex recu ⁇ ing structures.
  • the modify recu ⁇ ing time period module 16004 queries the Yearly options, displays them, and allows the actor to modify the options, choosing between two sets: ° Specific Month and Specific Day: June 15th, November 2
  • 16004 queries the Monthly options, displays them, and allows the actor to choose between two sets:
  • the modify recu ⁇ ing time period module 16004 displays the Weekly options and allows the actor to enter the day of the week: Tuesday
  • the modify recurring time period module 16004 queries and displays nothing.
  • Reports are a critical part of the Licensing module 1102. It is through reports that the license administrator and auditor (or any other user) obtain a great amount of useful information from system. All available reports are listed in a reports pane 10804 of a reports view 10802 (FIG. 108).
  • a report engine is used to generate the reports.
  • the licensing system 1102 When the user selects a report, the licensing system 1102 generates one or more commands that collectively encapsulates the user-selected report type and any user-provided parameters. The details of these commands will be apparent to persons skilled in the relevant art(s). These commands are in the language of the report engine.
  • the report engine generates the report pursuant to the commands. In doing so, the report engine accesses data (as indicated in the commands) in the databases discussed herein.
  • a commercial reporting module is used as the report engine, such as the commercially available Crystal Reports product.
  • the generate report use case 10902 is diagramed in FLG. 109.
  • the Generate report module 1788 runs and displays or prints the selected report.
  • the Print Object use case or related print use case is used. The operation of this use case is further described below.
  • Step 1 The Actor begins the transaction to run a report.
  • Step 2. The Generate report module 1788 constructs a list of available reports, displaying the name and description for the report in the reports view 10802 (FIG. 108).
  • Step 3 The Actor selects a report and requests that it be run, supplying appropriate parameters through a parameter form as requested and required, including the report destination (print or screen or file), ending the transaction.
  • Step 4. The Generate report module 1788 runs the report and sends it to the indicated destination.
  • This report lists the license agreements for each licensed LP asset package, providing the payment amount allocated to the asset package and the expected revenue.
  • An example ff Asset - Agreement Financial Detail (Summary of Intellectual Property) report is shown in FIGS. 111A-111D.
  • ° Licensee Profile This graph and detail report provides an overall view of a licensee's agreements. The graph presents total allocated payments and total expected revenue for each agreement.
  • An example Licensee Profile report is shown in FIGS. 112A-112F.
  • ° Agreement Summary The purpose of this report is to provide "front page" agreement and contact information and to list the compensation terms of the agreement. An example of this report is shown in FIG. 113.
  • the Intellectual Property Licensee Summary Report provides a summary of agreements for each licensee.
  • the Overdue Payment Graph shows Statement Received dates, Term total by due date, Payment total by payment date with some sort of flag and value for overdue interest owed or paid.
  • the Draft License is a report that is in the form of a license agreement document, that is generated by the system based on information in the databases. This draft document can be modified as necessary to produce the actual license agreement document.
  • Licensing system security includes the security features described above. In other embodiments, Licensing system security includes any combination of the above with one or more other features, such as the following administrative use cases, the ability to assign a security classification in the various document and payment entry and modification use cases, and the ability to change privileges on asset groups.
  • the administer users use case 11802 is diagramed in FIG. 118. According to this use case, the system Administrator creates, modifies, and/or removes users from the core database 1208.
  • Step 1 The System Administrator starts the transaction.
  • Step 2. The Administer entities module 1715 displays a list of users ordered by name, displaying the User Name, User Full Name, and Password (the password field appears but the actual password does not); there is also a Confirm Password for validating password entry.
  • Step 3. The System Administer takes one of the following actions:
  • Step 3.1 The System Administrator creates a new User, entering the User Name, the Full_Name, and the Password (twice) (the Administer entities module 1715 generates the User LD). The Administer entities module 1715 encrypts the password.
  • Step 3.2 The System Administrator selects one of the cu ⁇ ent
  • Step 3.3 The System Administrator selects one of the cu ⁇ ent
  • Step 4. The System Administrator ends the transaction.
  • Step 5 The Administer entities module 1715 commits the changes in the core database 1208.
  • the Administer entities module 1715 confirms the commit to the System Administrator.
  • This use case has a number of extensions: ° ff the System Administrator presses FI or the equivalent, the application extends the use case with the Display Help use case.
  • the Administer entities module 1715 deletes the information from the Licensing database 1204 and moves it to the Recycle Bin (implementation may differ regarding details on defe ⁇ ing the actual SQL deletes, and there is no notification of commit to the System Administrator).
  • the Administer entities module 1715 confirms the commit to the System Administrator. At any time until clearing the Recycle Bin, the administrator can restore the removed User and its related information.
  • the administer security classes use case 11902 is diagramed in FIG. 119.
  • the system Administrator sees a list of all security classes.
  • the system Administrator can add a new class to the list, can modify the name and access control list of a class, or can remove a class. This use case is further described below.
  • Step 1 The System Administrator starts the transaction.
  • Step 2. The Administer security classes module 1717 displays a list of Security Classes, displaying the Security Class LD and Name, and a list of the Entities, displaying the Entity LD and User Name.
  • Step 3 The System Administer takes one of the following actions:
  • Step 3.1 The System Administrator creates a new Security
  • the Administer security classes module 1717 enter the Name (the Administer security classes module 1717 generates the Security Class LD), and requests that the LPAM Security Subsystem create the object.
  • Step 3.2 The System Administrator selects one of the cu ⁇ ent
  • Step 3.3 The System Administrator selects one of the cu ⁇ ent
  • Step 3.4 The System Administrator selects a Security Class.
  • the Administer security classes module 1717 displays the permissions for that Security Class for each Entity.
  • the System Administrator modifies the permissions for any entity, including those with no permissions.
  • the System Administrator requests the LPAM Security Subsystem 1602 to set the permissions for the modified Security Class and Entities.
  • Step 4 The System Administrator ends the transaction.
  • Step 5. The Administer security classes module 1717 commits the changes in the Licensing Database 1204.
  • the Administer security classes module 1717 confirms the commit to the System Administrator. At any time, if the System Administrator presses FI or the equivalent, the application extends the use case with the Display Help use case. Grant Permissions
  • the grant permissions use case 12002 is diagramed in FIG. 120.
  • the System Administrator selects a secure object (an asset package or classifier), selects an entity (user or user group), and grants read, write, and or delete permission to the entity for the object.
  • the grant permissions module 1719 makes the permissions permanent through the LPAM Security Subsystem 1602. This use case is further described below.
  • Step 1 The System Administrator starts the transaction.
  • the Grant permissions module 1719 displays a list of the secure objects to which the System Administrator has access based on their cu ⁇ ent authentication user name. It gets this from the IPAM Security Subsystem 1602.
  • the Grant permissions module 1719 displays the objects sorted into two groups, asset packages and classifiers, distinguishing them by type (an icon, separate panes, or whatever) .
  • the asset packages display the Package OLD and the Name.
  • the classifiers display the Security Class OLD and the Name.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • Human Resources & Organizations (AREA)
  • Data Mining & Analysis (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Operations Research (AREA)
  • Quality & Reliability (AREA)
  • Tourism & Hospitality (AREA)
  • General Business, Economics & Management (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

Système, procédé et programme informatiques servant à rechercher, à analyser et à présenter sous forme de rapport des informations relatives à des transactions concernant la propriété intellectuelle (IP), y compris des licences et accords apparentés, et comprenant un serveur d'entreprise (214), un réseau (212), des clients de réseau (206A-C) et des bases de données (216), ainsi qu'un serveur Web (210) et des clients Web (204A-B). Le serveur d'entreprise (214) comporte une interface de réseau (301), un module de sécurité (302), un module (320) d'interface de base de données et différents modules d'interface d'utilisateurs, tels qu'un module d'administration (318), un module (308) de mémorisation et d'extraction de documents et des modules d'analyse (316).
PCT/US1999/019050 1998-08-21 1999-08-23 Systeme, procede et programme informatiques servant a gerer et a analyser des transactions relatives a la propriete intellectuelle WO2000011575A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU57808/99A AU5780899A (en) 1998-08-21 1999-08-23 System, method, and computer program product for managing and analyzing intellectual property (ip) related transactions

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US13836898A 1998-08-21 1998-08-21
US09/138,368 1998-08-21

Publications (2)

Publication Number Publication Date
WO2000011575A1 true WO2000011575A1 (fr) 2000-03-02
WO2000011575A9 WO2000011575A9 (fr) 2000-10-26

Family

ID=22481711

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US1999/019050 WO2000011575A1 (fr) 1998-08-21 1999-08-23 Systeme, procede et programme informatiques servant a gerer et a analyser des transactions relatives a la propriete intellectuelle

Country Status (2)

Country Link
AU (1) AU5780899A (fr)
WO (1) WO2000011575A1 (fr)

Cited By (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2368672A (en) * 2000-04-19 2002-05-08 Ford Global Tech Inc Online invention disclosure system
US7117443B1 (en) 2001-09-24 2006-10-03 Zilka Kevin J Network browser graphical user interface for managing web content
EP1525540A4 (fr) * 2001-06-29 2006-10-04 Guerry Leonard Grune Recherche simultanee en propriete intellectuelle et systeme et methodologie d'evaluation (sips-vsm)
US7194691B1 (en) 2001-09-24 2007-03-20 Aloft Media, Llc Network browser window with adjacent identifier selector interface for storing web content
US7523126B2 (en) 1997-06-02 2009-04-21 Rose Blush Software Llc Using hyperbolic trees to visualize data generated by patent-centric and group-oriented data processing
US7716060B2 (en) 1999-03-02 2010-05-11 Germeraad Paul B Patent-related tools and methodology for use in the merger and acquisition process
US7966328B2 (en) 1999-03-02 2011-06-21 Rose Blush Software Llc Patent-related tools and methodology for use in research and development projects
US20120323748A1 (en) * 2001-08-28 2012-12-20 Lee Eugene M Method and system for tracking compliance of licensee activity with licenses
US9823838B2 (en) 2010-11-30 2017-11-21 Cypress Lake Software, Inc. Methods, systems, and computer program products for binding attributes between visual components
US9841878B1 (en) 2010-08-26 2017-12-12 Cypress Lake Software, Inc. Methods, systems, and computer program products for navigating between visual components
US10397639B1 (en) 2010-01-29 2019-08-27 Sitting Man, Llc Hot key systems and methods

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5251294A (en) * 1990-02-07 1993-10-05 Abelow Daniel H Accessing, assembling, and using bodies of information
US5444779A (en) * 1993-10-18 1995-08-22 Xerox Corporation Electronic copyright royalty accounting system using glyphs
US5530520A (en) * 1994-12-15 1996-06-25 Xerox Corporation Method of allocating copyright revenues arising from reprographic device use
US5634012A (en) * 1994-11-23 1997-05-27 Xerox Corporation System for controlling the distribution and use of digital works having a fee reporting mechanism
US5875431A (en) * 1996-03-15 1999-02-23 Heckman; Frank Legal strategic analysis planning and evaluation control system and method
US5892900A (en) * 1996-08-30 1999-04-06 Intertrust Technologies Corp. Systems and methods for secure transaction management and electronic rights protection

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5251294A (en) * 1990-02-07 1993-10-05 Abelow Daniel H Accessing, assembling, and using bodies of information
US5444779A (en) * 1993-10-18 1995-08-22 Xerox Corporation Electronic copyright royalty accounting system using glyphs
US5634012A (en) * 1994-11-23 1997-05-27 Xerox Corporation System for controlling the distribution and use of digital works having a fee reporting mechanism
US5530520A (en) * 1994-12-15 1996-06-25 Xerox Corporation Method of allocating copyright revenues arising from reprographic device use
US5875431A (en) * 1996-03-15 1999-02-23 Heckman; Frank Legal strategic analysis planning and evaluation control system and method
US5892900A (en) * 1996-08-30 1999-04-06 Intertrust Technologies Corp. Systems and methods for secure transaction management and electronic rights protection

Cited By (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7523126B2 (en) 1997-06-02 2009-04-21 Rose Blush Software Llc Using hyperbolic trees to visualize data generated by patent-centric and group-oriented data processing
US7797336B2 (en) 1997-06-02 2010-09-14 Tim W Blair System, method, and computer program product for knowledge management
US7966328B2 (en) 1999-03-02 2011-06-21 Rose Blush Software Llc Patent-related tools and methodology for use in research and development projects
US7716060B2 (en) 1999-03-02 2010-05-11 Germeraad Paul B Patent-related tools and methodology for use in the merger and acquisition process
GB2368672A (en) * 2000-04-19 2002-05-08 Ford Global Tech Inc Online invention disclosure system
US20130013295A1 (en) * 2001-03-21 2013-01-10 Lee Eugene M Method and system for providing initial patent claim analysis
EP1525540A4 (fr) * 2001-06-29 2006-10-04 Guerry Leonard Grune Recherche simultanee en propriete intellectuelle et systeme et methodologie d'evaluation (sips-vsm)
US20120323748A1 (en) * 2001-08-28 2012-12-20 Lee Eugene M Method and system for tracking compliance of licensee activity with licenses
US7194691B1 (en) 2001-09-24 2007-03-20 Aloft Media, Llc Network browser window with adjacent identifier selector interface for storing web content
US7117443B1 (en) 2001-09-24 2006-10-03 Zilka Kevin J Network browser graphical user interface for managing web content
US10397639B1 (en) 2010-01-29 2019-08-27 Sitting Man, Llc Hot key systems and methods
US11089353B1 (en) 2010-01-29 2021-08-10 American Inventor Tech, Llc Hot key systems and methods
US9841878B1 (en) 2010-08-26 2017-12-12 Cypress Lake Software, Inc. Methods, systems, and computer program products for navigating between visual components
US10338779B1 (en) 2010-08-26 2019-07-02 Cypress Lake Software, Inc Methods, systems, and computer program products for navigating between visual components
US10496254B1 (en) 2010-08-26 2019-12-03 Cypress Lake Software, Inc. Navigation methods, systems, and computer program products
US9823838B2 (en) 2010-11-30 2017-11-21 Cypress Lake Software, Inc. Methods, systems, and computer program products for binding attributes between visual components
US9870145B2 (en) 2010-11-30 2018-01-16 Cypress Lake Software, Inc. Multiple-application mobile device methods, systems, and computer program products
US10437443B1 (en) 2010-11-30 2019-10-08 Cypress Lake Software, Inc. Multiple-application mobile device methods, systems, and computer program products

Also Published As

Publication number Publication date
WO2000011575A9 (fr) 2000-10-26
AU5780899A (en) 2000-03-14

Similar Documents

Publication Publication Date Title
US7949728B2 (en) System, method, and computer program product for managing and analyzing intellectual property (IP) related transactions
Cong et al. Technological disruption in accounting and auditing
CN111815282A (zh) 信息系统工程监理项目导引管理系统
US20130013520A1 (en) Electronic licensing system and method
US20030172020A1 (en) Integrated intellectual asset management system and method
US20020116363A1 (en) Method of deleting unnecessary information from a database
US8266067B1 (en) Method and system for automatic scoring of the intellectual properties
US20020161733A1 (en) Method of creating electronic prosecution experience for patent applicant
US20050033669A1 (en) Philanthropy management system and methods of use and doing business
US20030046307A1 (en) Using hyperbolic trees to visualize data generated by patent-centric and group-oriented data processing
US20020111824A1 (en) Method of defining workflow rules for managing intellectual property
US20070073626A1 (en) Integrated media management and rights distribution apparatus
US20110106676A1 (en) System and method for comprehensive management of company equity structures and related company documents with financial and human resource system integration
US20040162737A1 (en) Agreement management system
CN1653450A (zh) 业务分析工具
JP2011154696A (ja) データオブジェクトのコンテキストを処理する知的所有権資産マネージャ（ｉｐａｍ）
WO2010042513A2 (fr) Facturation, enregistrement et gestion de documents
WO2000011575A1 (fr) Systeme, procede et programme informatiques servant a gerer et a analyser des transactions relatives a la propriete intellectuelle
JP2008140411A (ja) 契約管理システム
Reineke et al. When do firms use one set of books in an international tax compliance game?
Bonsón et al. The role of XBRL in enhanced business reporting (EBR)
US20060253333A1 (en) Centralized distributions
WO2001016674A1 (fr) Procede et dispositif servant a mettre en correlation des informations de contrat de licence avec des configurations logicielles et materielles
Moen et al. The challenges of nonstandardized vendor usage data in a statewide metasearch environment: The Library of Texas experience
O’Leary Knowledge Management in Enterprise Resource Planning Systems

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AU CA JP KR

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE

121 Ep: the epo has been informed by wipo that ep was designated in this application
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
AK Designated states

Kind code of ref document: C2

Designated state(s): AU CA JP KR

AL Designated countries for regional patents

Kind code of ref document: C2

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE

COP Corrected version of pamphlet

Free format text: PAGES 5 AND 39, DESCRIPTION, REPLACED BY NEW PAGES 5 AND 39; PAGES 1/193-193/193, DRAWINGS, REPLACED BY NEW PAGES 1/188-188/188; DUE TO LATE TRANSMITTAL BY THE RECEIVING OFFICE

122 Ep: pct application non-entry in european phase