Title of Invention: Licensing management system and method in which datagrams including an address of a licensee and indicative of use of a licensed product are sent from the licensee's site
Abstract: A license management system and method for recording the use of a licensed product, and for controlling its use in accordance with the terms of the license. A licensed product invokes a license check monitor at regular time intervals. The monitor generates request datagrams which identify the licensee and the product and sends the request datagrams over a communications facility to a license control system. The license control system maintains a record of the received datagrams, and compares the received datagrams to data stored in its licensee database. Consequently, the license control system transmits reply datagrams with either a denial or an approval message to the monitor. The monitor terminates further use of the product if it receives a denial message. The monitor generates its own denial message if its request datagrams are unanswered after a predetermined interval of time. The datagrams are counted at the control system to provide billing information.
Detailed Description: Part PAC: DETAILED DESCRIPTION OF THE PRESENTLY PREFERRED EXEMPLARY EMBODIMENT
Part PAR: As shown in FIG. 1, a licensed product 1 is located at a licensee's site. Product 1 may include a data portion 1B and a functional portion 1A such as computer software product or any other kind of information product used to control use of data portion 1B. If data portion 1B is CD-ROM database information, functional portion 1A should enable the licensee to search indexes and display text. If data portion 1B is video information, functional portion 1A should control the display of the video information. For audio information, functional portion 1A should play the audio information. If data portion 1B is an electronic book, functional portion 1A should display and turn pages. The above examples show some of the ways functional portion 1A can control data portion 1B; however, they are hardly exhaustive.
Part PAR_2: By including in product 1 both information and software which controls the information, product 1 is an executable product. Non-software information in product 1 is preferably encrypted so that it cannot be easily extracted from the product.
Part PAR_3: License check monitor 2 sends license datagrams 3 to the licensor and also receives license datagrams 3 from the licensor. License check monitor 2 also prevents further use of product 1 when a datagram 3 containing a "denial" message is received.
Part PAR_4: License datagrams 3 are messages that describe information related to the use of licensed product 1. Datagrams 3 are sent over a communications network between the licensee and licensor. Initially, the licensee sends a request datagram 3 over the network to the licensor. The licensor then returns a reply datagram containing either an approval or denial. It is also possible to implement the present invention by having the licensor transmit a reply datagram only for approvals.
Part PAR_5: At the licensor's site, license control system 4 makes licensing decisions by comparing request datagram 3 with license records 5. After the comparison, control system 4 stores information related to request datagram 3 into history of license datagram record 6. It is noted that request datagrams 3 are periodically sent while product 1 is in use. Thus, the history of license datagrams in record 6 provides means for measuring the duration of use of product 1.
Part PAR_6: Representations of data and records stored at the licensee's site, contained in datagrams, and stored at the licensor's site are illustrated in FIG. 2. At the licensee's site, network service 7, which handles delivery and transmission of datagrams 3, supplies network address 8. It is by this address that license control system 4 identifies a location of use of product 1.
Part PAR_7: Licensed product record 9 is contained within monitor 2. Within the license product record 9 is an identification record 10, which contains the following two items: licensor's network address 11, and product model number 12 that identifies product 1. When a licensor has only one product, or uses different licensor network addresses 11 for each product, product model number 12 may not be needed.
Part PAR_8: Datagram sent record 13 stores information about the last sent datagram 3. It includes a datagram number 14, which uniquely identifies the last transmitted datagram 3, and the date and time 15 when the last datagram 3 was sent from the licensee's site.
Part PAR_9: Licensed product record 9 also contains control parameters record 16, which is used for controlling the timing of key events in the communication of license check monitor 2 with license control system 4. Send interval 17 specifies a time interval between each transmission of a new datagram 3 from the licensee to the licensor.
Part PAR_10: Wait interval 18 is the length of time that monitor 2 waits to receive a reply datagram 3 before resending the same request datagram 3. The duration of this interval depends on the speed of the communications network being used to deliver datagrams 3.
Part PAR_11: Disconnect allowed interval 19 is the duration of time that monitor 2 allows product 1 to be used without a reply datagram 3 from the licensor. The duration of this interval depends on the reliability of the communications network. The interval must be long enough to take into consideration network downtime. For example, suppose a message was sent from the licensor and the network went down just afterwards. Disconnect allowed interval 19 should be long enough to allow the network to resume its normal operation and successfully deliver datagrams 3 from the licensor; otherwise, the licensee would be forced to stop using product 1 until the network was operational.
Part PAR_12: License datagram 3 contains header 20. Header 20 is used during execution of low level communication protocols within the network. Source network address 21 is the network address from where datagram 3 is sent. Destination network address 22 is the network address to where datagram 3 is sent. Additional data may be included in header 20 if required by low level protocols used in delivering datagrams 3.
Part PAR_13: Data 23, a part of datagram 3, conveys a message, and contains a number of fields. Product model number 24 and datagram number 25 identify product 1 and datagram 3, respectively. It is noted that retransmitted datagrams have an identical datagram number. Duplicate datagrams must be identified at a licensor's site so that they do not all contribute in billing a licensee.
Part PAR_14: Each datagram number 25 is unique for each request datagram 3 transmitted from the licensee, except for retransmitted datagrams. This allows a reply datagram 3 received by a licensee to be verified as an actual reply to a request datagram 3 from that licensee, as explained below.
Part PAR_15: Number of processes running 26 is the number of concurrent uses of product 1 at the time datagram 3 is sent. Authorization code 27 is used on reply datagrams 3 to indicate an approval or a denial. Message text 28 contains a message which will be displayed to the user upon a denial.
Part PAR_16: License database 29 at the licensor's site holds records of information about customers, licenses, and license usage. The types of information within license database 29 of the present embodiment are shown in FIG. 2. However, a specific license management system may require its license database to hold types of information other than those in FIG. 2. For example, licensee name and address may be incorporated as a part of a license database 29.
Part PAR_17: License record 5 contains information on licenses. Licensee network address 30 identifies a precise network node which is licensed to use product 1. If request datagrams are received which do not originate from known licensee network addresses 30, reply datagrams containing denial messages are transmitted. Product model number 31 is the model number of a licensed product. Termination date 32 is the expiration date of a license. When the license of a product is issued for an unlimited duration, termination date 32 should reflect a date very far into the future, relative to the licensing date.
Part PAR_18: The present embodiment allows licenses to be paid for in a lease-like or rental fashion. If a licensee were to rent or lease product 1, paid through date 33 would reflect the date through which the licensee has paid for using the product. Grace period 34 is the time interval for which the licensee is allowed to be delinquent before services are disconnected. Grace period 34 would reflect a very large time interval if the license is not of a lease-like or rental type. When the license provides for a limit on the number of concurrent uses of a product 1, number of processes licensed 35 contains the limiting number. When the license does not provide for such a limit, number of processes 35 should be a very large number.
Part PAR_19: History of license datagrams 6 is an archive of datagrams 3 received from the licensee.
Part PAR_20: FIG. 3 illustrates operations executed at the licensee's site and at the licensor's site. An overview of the processing at the licensee's site is described by steps 101.0 to 106.0, and an overview of the processing at the licensor's site is described by steps 107.0 to 110.0.
Part PAR_21: At the licensee's site, at step 101.0, product 1 invokes monitor 2. This is accomplished by first establishing monitor 2 as a handler for a timer expiration interrupt signal and for received datagrams 3. Next, a timer is set with a very short time to cause an initial call to monitor 2. At step 102.0, monitor 2 computes a time 36 since the last datagram was sent by determining the difference between the current date and sent time and date and time 15 that a datagram was last sent from the licensee's site. When product 1 commences execution, datagram sent date and time 15 is set to "null." Thus, time since send 36 is very large at the beginning of the monitor's execution. At step 103.0, time since send 36 is compared to send interval 17. If time since send 36 is greater than send interval 17, then a request datagram is transmitted, per the steps described in FIG. 4. Step 104.0 first checks if a reply to the last datagram has arrived and if wait interval 18 has expired. If a reply has not arrived and the wait interval has expired, steps 104.1-104.3 (FIG. 5) are executed. Step 105.0 processes authorization code 27 in a reply when the reply is received, in accordance with steps 105.1 to 105.5 (FIG. 6). At step 106.0, product 1 resumes normal execution of its programs until the next interrupt signal is generated.
Part PAR_22: At the licensor's site, license control system 4 receives and processes datagram 3, in accordance with steps 107.0 to 110.0. Step 107.0 receives request datagram 3. Step 108.0 generates authorization code 27, per steps 108.1 to 108.8 (FIG. 7). Step 109.0 creates reply datagram 3 and transmits the datagram to the licensee via steps 109.1 to 109.5 (FIG. 8).
Part PAR_23: FIG. 4 shows the procedure which monitor 2 follows for sending request datagram 3 to the licensor. Step 103.1 sets source network address 21 in datagram 3 to the network address 8 of the licensee's location on the network. Step 103.2 sets destination network address 22 to licensor's network address 11. Step 103.3 encrypts product model number 12 for datagram 3. Step 103.4 assigns a unique number to datagram 3, encrypts the number, and stores it as datagram number 14. This number is altered when an entirely new datagram 3 is sent. Datagrams which are retransmitted have the same datagram number 25 as the original. As already explained, this allows license control system 4 to identify duplicate datagrams.
Part PAR_24: Step 103.5 counts the number of processes using product 1, currently running, encrypts the count, and stores the encryption as the number of processes running 26. In the UNIX operating system, this procedure could be performed using the command "ps" to obtain a list of current processes, the command "grep" to extract the processes of product 1, and "wc" to count the number of processes. Step 103.6 sets authorization code 27 to number 255 and encrypts the number.
Part PAR_25: Number 255 indicates that datagram 3 is a request for authorization. Such an indication is needed to guard the present system against the following steps for circumventing the present invention: intercepting outgoing datagrams; and inputting the intercepted datagrams to monitor 2.
Part PAR_26: Step 103.7 stores the current date and time as sent date & time 15. This date is needed to compute when to send the next datagram 3. Step 103.8 assigns a value to send interval 17, which sets an alarm for invoking monitor 2 to send the next datagram 3. Step 103.9 sends datagram 3.
Part PAR_27: In the present embodiment a datagram is transmitted via a connectionless datagram service. Methods for transmission are well documented for some networking systems. For example, TCP/IP (Transport Control Protocol/Internet Protocol) includes a connectionless protocol called UDP (User Datagram Protocol). A method for sending a datagram using UDP protocol from a SUN Microsystem computer is documented in a SUN manual titled, Network Programming Guide, in section 9 titled "Transport Level Interface Programming."
Part PAR_28: Step 103.10 sets another alarm using wait interval 18 for retransmitting datagram 3, if no reply datagram has been received. The alarm causes monitor 2 to be invoked for checking whether a reply datagram 3 has been received. Monitor 2 will transmit a duplicate of the previously transmitted datagram, if no reply has been received. After the execution of step 103.10, "Send License Datagram" procedure returns system control to step 104.0 in FIG. 3.
Part PAR_29: FIG. 5 shows the operation of the "Reply Datagram is Overdue" procedure. Step 104.1 compares time since the last datagram was sent 36 to disconnect allowed interval 19, which, as described above, is the interval that product 1 is allowed to operate even if a reply is overdue. If time since send 36 is smaller than disconnect allowed interval 19, datagram 3 is retransmitted via executing step 103.9 in FIG. 4. Step 104.2 "disconnects" product 1 from further service, if time since send 36 is greater than disconnect allowed interval 19.
Part PAR_30: Step 104.2 comprises a sequence of sub-steps 104.2.1-104.2.3. Step 104.2.1 assigns number 5 to authorization code 27 in the current datagram being processed. Value 5 is interpreted by monitor 2 as a denial. Step 104.2.2 sets message text 28 to the following: "A reply from licensor to numerous authorization requests was never received. This product must be connected to a communications network in order to function." Step 104.2.3 transfers system control to step 105.3 in FIG. 6. Step 105.3 processes the current denial datagram 3 as if it were just received.
Part PAR_31: Through the execution of steps 104.1-104.3, the present system permits the use of product 1 for a prescribed period of time. After the prescribed period of time has elapsed, the present system generates a denial.
Part PAR_32: FIG. 6 illustrates the steps which monitor 2 follows in processing a reply datagram 3. Step 105.1 decrypts all encrypted data in the received datagram. Step 105.2 compares datagram number 25 with datagram number 14 associated with the last datagram. If datagram number 25 is not equal to datagram number 14, step 105.2 ignores the current datagram and transfers procedural control to step 103.9 (FIG. 4) in order to resend the last transmitted datagram. After disconnect allowed interval 19 elapses, monitor 2 generates a denial.
Part PAR_33: In essence, step 105.2 guards against the circumvention of the present invention via: (1) intercepting a reply datagram 3 (from the licensor) containing an approval (2) storing the reply datagram 3; and (3) inputting the stored datagram to monitor 2.
Part PAR_34: If the execution of step 105.2 does not transfer its procedural control to step 105.3, and if authorization control 27 is not zero (indicating an unqualified authorization has not been received), step 105.3 processes authorization code 27 via steps 105.3.1 to 105.3.3. Step 105.3.1 retrieves message text 28 from datagram 3. If message text 28 is null, then the current datagram 3 is ignored, and monitor 2 resends the last transmitted datagram 3. Step 105.3.1 further protects the present system from attempts to generate fake datagrams and to feed the fake datagrams to monitor 2 by checking for a proper authorization code of zero.
Part PAR_35: If message text 28 is not null, step 105.3.2 presents the message 28 to the user on an output device such as a CRT screen. Step 105.3.3 terminates the current use of product 1. This step may be implemented by subroutine or function call to a simple exit that saves any current user data to a file. Alternatively, product 1 may be designed so that, upon being directed to terminate further execution, it first gives the user an opportunity to save their data.
Part PAR_36: If authorization code 27 is zero, step 105.4 allows further use of product 1. Step 105.5 returns procedural control to 106.0 on FIG. 3.
Part PAR_37: FIG. 7 shows a sequence of operations within the "Generate Authorization Code" procedure. The procedure produces appropriate authorization code 27 when a request datagram 3 is received at the licensor's site.
Part PAR_38: Step 108.1 decrypts all encrypted data in the received datagram 3. Using source network address 21 and product model number 24 in the datagram 3, step 108.2 searches the license database 29 for matching licensee network address 30 and product model number 31. If license database 29 does not contain a record of product model number 24 of the product 1 being licensed to the licensee, step 108.3 sets authorization code 27 of its reply datagram 3 to 1 (i.e., the sending node is not a registered address) and authorization is denied.
Part PAR_39: Step 108.3 prevents copies of product 1 from being installed on multiple nodes independently of whether they are within or outside the licensee's organization. Step 108.3 also prevents the licensee from transporting product 1 from one node to another node without the licensor's approval. This is important because the two nodes may have different processing capacities, and they may be billable at different rates.
Part PAR_40: If the date a request datagram is received is later than license termination date 32, step 108.4 sets authorization code 27 to number 2 (i.e., license has expired). Step 108.4 allows the licensor to fix licensing periods, or to determine free trial periods for the use of the product. The licensing period may be extended by resetting license termination date 32 at the licensor's site.
Part PAR_41: If the date when the datagram is received is later than the paid through date 33 as extended by the grace period 34, step 108.5 sets authorization code 27 to 3 (i.e., payment is past due).
Part PAR_42: If the number of processes running 26 exceeds a licensed number of concurrent uses of product 1 (at a particular node), then step 108.6 sets authorization code 27 to 4 (i.e. concurrent process usage limit is exceeded).
Part PAR_43: Step 108.7 sets authorization code 27 to 0 indicating processing can continue. It is noted that steps 108.3-108.7 are a part of a
Part PA1: IF (x1) then (y1) PA1 ELSE if (x2) then (y2) PA1 ELSE if (x3) then (y3)
Part PAL: statement of a procedure (e.g., FORTRAN, PASCAL, C, etc). Thus, only one of the steps 108.3-108.7 is executed. Step 108.7 sets authorization code 27 to 0 (indicating approval of further use) only if steps 108.3-108.6 do not execute the THEN portion of each step. Step 108.7 also stores the received datagram 3 in history of license datagrams 6.
Part PAR_44: Step 108.8 is the last of authorization processing rules 108.1-108.7. After the execution of steps 108.3-108.7, step 108.8 returns procedural control to step 109.0 in FIG. 3.
Part PAR_45: FIG. 8 illustrates the steps which license control system 4 follows to send reply datagram 3 to the licensee.
Part PAR_46: Step 109.1 encrypts authorization code 27 and writes the encrypted code into datagram 3. Next, step 109.2 writes message text 28 corresponding to authorization code 27 into datagram 3.
Part PAR_47: Step 109.2 may be replaced with the following method for relaying proper messages to a product user. Proper messages corresponding to each authorization code is stored in monitor 2 at each licensee's site. Upon reception of a reply datagram 3, monitor 2 would locate within itself the proper message corresponding to the authorization code, and use the message for various purposes. This method would reduce the size of reply datagrams 3. However, if the licensor wanted to implement new denial codes, each product would need to somehow incorporate the new message associated with the new denial code into itself. The list of messages, one of which may be written as message text 28, are as follows:
Part TBL: ______________________________________ AUTHORIZATION CODE TEXT MESSAGE ______________________________________ 1 This product is not licensed to run at this location. Please contact the licensor to either license this product, or move an existing license of your organization to this location. Use of this product at this location is discontinued until this problem is resolved. 2 Your license on this product has expired. Please contact licensor in order to have your license extended. Use of this product is discontinued until this problem is resolved. 3 Payment on this licensed product is over due and past your grace period. Please have your accounting department send payment in order to continue your license. Use of this product is discontinued until this problem is resolved. 4 Your current use of this licensed product exceeds limits for the number of uses your organization has licensed. Please try again later. 5 A reply from licensor to numerous authorization requests was never received. This product must be connected to a communications network in order to function. 0 Authorization is OK. There is no message. ______________________________________
Part PAR_48: Step 109.3 swaps source network address 21 and destination network address 22. Step 109.4 transmits datagram 3 back to monitor 2.
Part PAR_49: At step 109.5, a communications network delivers datagram 3 to monitor 2. Subsequently, procedural control returns to step 107.0 in FIG. 3 to process the next datagram 3.
Part PAR_50: Although only a few exemplary embodiments of this invention have been described in detail above, those skilled in the art will readily appreciate that many modifications are possible in the preferred embodiments without materially departing from the novel teachings and advantages of this invention. For example, product 1 was described as sometimes consisting of information as well as software which controls the information. This approach provides the greatest flexibility, but it is also possible to include the software which controls the information in the networked machine at the licensee's site. In this case, product 1 is split, with part of it on media and part on the licensee's machine. By doing this, some space can be saved on the media containing product 1, but the capabilities of these products will be limited by the standard functions available on these machines.
Part PAR_51: Also, the presently described embodiment includes a product 1 which is at the licensee's site. This implies that product 1 is on some physical media such as diskette, tape, or CD. However, product 1 can be electronically delivered over communications lines to the licensee and therefore might exist in the memory of the licensee's machine, rather than any physical media. In the case of a product such as music, radio programs and the like, product 1 may even be broadcast to the licensee's site for playback; thus, the product 1 would not even be "resident" in the licensee's machine.
Part PAR_52: The presently described embodiment allows the licensee to access the licensed product concurrent with the sending and receiving of datagram 3. In this way, the present invention does not inconvenience the legitimate licensee; however, for sensitive licensed products such as confidential information, the license check monitor 2 can prevent access to the product 1 until an authorization reply datagram 3 is received.
Part PAR_53: Further, monitor 2 could be realized as an integral part of product 1. Monitor 2 could also be implemented as: 1) a separate process which is the parent process of product 1 (Such a parent process would have the authority to cancel the use of product 1); 2) a single system level task which controls license checking of all products at the licensee's site; and 3) custom logic in a digital integrated circuit (the present invention could be implemented as hardware instead of software).
Part PAR_54: Also, though the above embodiment has been described as being implemented on a computer system network where operator messages are provided on a CRT monitor or the like, the invention may be practiced on other hardware platforms by incorporating appropriate changes known to those of ordinary skill in the art. For example, in an alternative hardware embodiment such as a music or video playback device, monitor 2 is invoked by the licensee's action of pushing the "play" or similar button, and in a broadcast music application or similar system, the monitor may be invoked simply by turning the device on. The processing of monitor 2 is as described in the presently described embodiment. However, when a denial message is received or generated, monitor 2 must be able to switch "play" to "off".
Part PAR_55: The presently described embodiment is designed to be used in conjunction with a connectionless UDP (User Datagram Protocol) in the TCP/IP protocol suite as an underlying protocol. However, the present invention could also be realized using a slower, connectionless protocol such as electronic mail or a variety of connection protocols (e.g., File Transfer Protocols (FTP), Telnet).
Part PAR_56: It is noted that protocol suites quite different from TCP/IP could be used, such as ISO (International Standards Organization) protocol. In addition, datagrams 3 could be sent over telephone systems with communications protocols such as those specified by CCITT (Consultative Committee on International Telephony and Telegraphy). In this case, telephone numbers could serve as network addresses 21, 22. Communications protocols for wireless communications such as cellular telephone can also be used to send the datagram 3.
Part PAR_57: Accordingly, all such modifications are intended to be included within the scope of this invention as defined by the following claims.


{'bibliographic_information': '{\'Patent Number\': \'059405040\', \'Series Code\': \'7\', \'Application Number\': \'9079343\', \'Application Type\': \'1\', \'Art unit\': \'273\', \'Application Filing Date\': \'19920629\', \'Title of Invention\': "Licensing management system and method in which datagrams including an address of a licensee and indicative of use of a licensed product are sent from the licensee\'s site", \'Issue Date\': \'19990817\', \'Number of Claims\': \'105\', \'Exemplary Claim Number(s)\': \'1\', \'Primary Examiner\': \'Kim; Kenneth S.\', \'Number of Drawing Sheets\': \'8\', \'Number of figures\': \'8\'}', 'source_file': './grant/1999/pftaps19990817_wk33.txt', 'source_data': 'USPTO-Grant'}