CONTROLLED TRANSFER OF INFORMATION IN COMPUTER NETWORKS
Reference to Appendix Text Appendix A is being submitted with the present application.
Background of the Invention The present invention relates to techniques for controlling transfers of information in computer networks, such as establishing communication channels between computers, transmitting smart digital offers based on information such as coupons and purchasing histories stored at the computer receiving the offer, automatically receiving data from a user's computer based on a personal profile and security profile of the user, and metering a user's access to linked information.
U.S. Patent Application Serial No. 08/168,519, filed December 16, 1993 by David K. Gifford and entitled "Digital Active Advertising," the entire disclosure of which is hereby incorporated herein in its entirety by reference, describes a network sales or payment system that includes at least a client computer and a payment computer. The client computer transmits a payment order and an authenticator to the payment computer. The payment computer verifies the authenticator, transmits a payment authorization message and an authenticator back to the client computer, and performs a payment settlement transaction.
U.S. Patent Application Serial No. 08/328,133, filed October 24, 1994 by Andrew C. Payne et al. and entitled "Network Sales System," the entire disclosure of which is hereby incorporated herein by reference, describes a network sales system in which a buyer computer transmits a payment order including a product identifier to a payment computer, which transmits an access message and an authenticator to a merchant
computer, which verifies the authenticator and causes the product to be sent to a user of the buyer computer. The payment computer stores the product identifier and the payment amount in a settlement database. A user at the buyer computer can transmit to the payment computer a request for an account statement, with an authenticator, and the payment computer verifies the authenticator and transmits a statement constructed from the settlement database to the buyer computer. One known technique for transferring information in computer networks includes programming a computer to obtain packages of Web pages. The computer obtains the packages of Web pages automatically, on a periodic basis, without direct input from the user. Summary of the Invention
One aspect of the invention features a network- based system for controlled transfer of information that includes a client computer, a server computer, and an information source computer interconnected by a computer network. The server computer transmits to the client computer a document containing a channel object corresponding to a communication service to be provided over an information transfer channel between the information source computer and the client computer. The client computer activates the channel object received from the server computer, and, in response to activation of the channel object, stores an access ticket that indicates that a user of the client computer permits the information source computer to communicate with the user over the channel. The information source computer transmits information to the client computer over the channel, and the client computer receives the information from the information source computer over the channel, based on the stored access ticket.
A user at the client computer can determine whether to activate a specific channel object received from the server computer and can specifically request that it be activated. Alternatively, the client computer can activate the channel object automatically if identifying data in the channel object specific to the information to be provided by the information source computers falls within parameters preset by the user such as a particular keyword phrase or a particular rating. The information transfer channel can be a broadcast or multicast channel, or it can simply be the computer network linking the client computer and the information source computer.
Another aspect of the invention features a network-based system for smart digital offer pricing that includes a client computer and an offer-providing server computer interconnected by a computer network. The offer-providing server computer transmits a document to the client computer that includes a smart digital offer object. The client computer stores user-specific information at the client computer, receives the document that includes the smart digital offer object, and activates the smart digital offer object at the client computer. Upon activation, the smart digital offer object provides an offer to the client computer based on the stored user-specific information. The client computer transmits an acceptance of the offer to the offer-providing server together with an authenticator. The offer-providing server verifies the authenticator and causes the offer to be fulfilled based on verification of the authenticator.
Because the smart digital offer object is executed at the client computer, it can efficiently use client- specific information that is stored at the client computer, even if the client computer is off-line and the
smart digital offer object has been received by e-mail, and it can minimize the load at the offer-providing server. In addition, the user-specific information examined by the smart digital offer object need not be revealed to the offer-providing server if the user does not accept the offer, because the client computer can contact the offer-providing server after activation of the smart digital offer object only if the user accepts the offer. The user-specific information may be a coupon transmitted by a coupon-providing server computer to the client computer together with an authenticator. The client computer causes the coupon information and the authenticator to be stored, and the smart digital offer object, when it is activated, verifies the authenticator. Another aspect of the invention features a network-based system for automatic transfer of information pertaining to a person profile of a user that includes a client computer and a server computer interconnected by a computer network. The server computer transmits to the client computer a document that includes a request for personal profile information pertaining to a user of the client computer. The client computer receives the document that includes the request for personal profile information, and activates a client avatar at the client computer. The client avatar compares the request for personal profile information with a security profile of the user limiting access to personal profile information and causes a subset of a personal profile of the user to be transmitted to the server computer based on the request for personal profile information and the security profile. The server computer transmits to the client computer information customized for the user based on the subset of the personal profile of the user.
The client avatar acts as an agent for the user by controlling the release of information from the client personal profile to the server computer. The client avatar makes it possible to store a single client personal profile at the client computer or an agency computer, rather than multiple personal profiles at multiple server computers, while at the same time limiting the release of certain information from the personal profile only to trusted servers or only upon specific authorization from the user.
Another aspect of the invention features a network-based system for metering of a user's access to linked information that includes a client computer and a server computer interconnected by a computer network. The server computer transmits to the client computer a document containing an embedded link. The client computer activates the embedded link when at least a portion of the document corresponding to the embedded link is displayed, records activation of the embedded link in a metering log, and causes information stored in the metering log pertaining to activation of the embedded link to be transmitted to the server computer.
This process makes it possible to charge a user on a per-usage basis for the user's access to information, without requiring the client computer to notify the server computer every time the user accesses the information. The per-usage charges can be assessed even if the client computer stores the documents in a cache from which the client computer periodically retrieves the documents. The information obtained from the metering log may alternatively be used solely for advertising feedback purposes, without any charges to the user.
Numerous other features, objects, and advantages of the invention will become apparent from the following
detailed description when read in connection with the accompanying drawings.
Brief Description of the Drawings Fig. 1 is a block diagram of a network-based system for controlled transfer of information.
Fig. 2 is a flowchart diagram detailing the operation of the network-based system of Fig. 1.
Fig. 3 is a block diagram of a network-based system for smart digital offer pricing. Figs. 4A and 4B are a flowchart diagram detailing the operation of the network-based system of Fig. 3. Fig. 5 is a block diagram of a network-based system for transfer of information pertaining to a personal profile of a user. Fig. 6 is a flowchart diagram detailing the operation of the network-based system of Fig. 5.
Fig. 7 is a block diagram of a network-based system for metering a user's access to linked information. Fig. 8 is a flowchart diagram detailing the operation of the network-based system of Fig. 7.
Detailed Description Referring to Fig. 1, a network-based system for controlled asynchronous transfer of information includes a client computer 10, operated by a user, that filters information transferred asynchronously to the client computer, a server computer 12 that transmits a document to the client computer containing a channel object that can be activated to authorize an asynchronous transfer of information, an information source computer 14 that asynchronously transfers the information, and an optional notification server 16 that acts as a trusted intermediary that filters asynchronously transferred information on behalf of the client computer. In certain implementations server computer 12 and information source
computer 14 are the same computer. As used herein, the term "asynchronous" transfer of information refers to a transfer of information from an information source computer that is initiated by the information source computer rather than by another computer to which the information source computer responds.
Client computer 10 or optional notification server 16 maintains an access control list 18 that stores access tickets that permit asynchronous transfers of information to the client computer or notification server. The access tickets are created upon activation of a channel object 20 received by client computer 10 from server computer 12. If optional notification server 16 is used to filter asynchronously transferred information on behalf of the client computer, the notification server maintains a list of messages 22 that can be retrieved by the client computer.
Referring to Fig. 2, in operation of the network- based system of Fig. 1, the client computer sends a message to the server computer (step 24) and the server responds by sending the client computer a document containing a channel object (step 26) . Embedded within the channel object are a description of an asynchronous communication service, keywords describing the actual semantic content of the information to be transferred, an icon for identifying the asynchronous communication service to the user, a rating ("G," "PG," "R") , an identification of the size of the information block to be transferred, and any other information that might be useful t the user.
The description of the asynchronous communication service in the channel object may include a certificate that includes an identification of the supplier of the information to be transmitted to the client computer, as well as the supplier's public key, the certificate being
signed by a certifying authority. This public key will be used by the client computer to authenticate the information to be transmitted to the client computer by the information source computer. The description of the asynchronous communication service in the channel object may specify a particular broadcast channel, such as a satellite feed channel on a portion of the internet or on a cable service, or a particular multicast channel, such as an Mbone channel. The description of the asynchronous communication service also specifies a particular time period during which the information will be transmitted asynchronously over the channel to many client computers.
When the document is displayed on the user computer, the icon contained in the channel object is displayed on the document as a representation of the channel object, and the user can determine from the document whether to authorize delivery of the content of the channel object as described in the document. The user can activate or select the channel object by clicking on a representation of the channel object on the document, or a channel object in a document or broadcast received by the client computer may be activated automatically by the computer if the keywords or the other identifying information contained in the channel object match preset parameters pre-programmed into the client computer as a personal profile of the user (step 28) . For example, the user may pre-program the computer to search for a keyword phrase such as "BUGS BUNNY" to automatically activate channel objects pertaining to BUGS BUNNY. Similarly, the user may authorize automatic activation of channel objects containing an embedded "G" rating, or automatic activation of only one megabyte of information per week.
Activation of the channel object causes an access ticket containing the description of the asynchronous communication service to be added to the client control list in the client computer, or causes the access ticket to be sent to the notification server, which adds it to the access control list (step 30) . The access ticket permits the information source computer to communicate asynchronously with the client computer over a channel specified by the channel object, which may be a broadcast or multicast channel at a specific time period, or which may be the computer network linking the client computer and the information source computer in the event that the information from the information source computer is to be received by means of an asynchronous communication over the computer network. Thus, the activation of a channel object initiates an asynchronous communication channel from the information source computer to the client computer and instructs the client computer that the information source computer is authorized to send information over the channel.
Once the channel object has been activated, the client computer notifies the server computer (or the information source computer, or another computer) that the access ticket was added to the access control list (step 32) and the server computer (or the information source computer, or another computer) records in a persistent database the client's interest in the channel object and sends a confirmation to the client computer that the client's interest in the channel object has been recorded (step 34) .
The information source computer (which may have access to the persistent database mentioned above and therefore may be informed of the client's interest) asynchronously sends information to the client computer or the notification server (step 36) over the channel
specified by the channel object. The information includes an identification of its supplier and is signed using a private key of a public/private key pair. The client computer or the notification server accepts the information based on the presence of the appropriate access ticket in the access control list (step 38) corresponding to the supplier of the information and based on the client computer's use of the public key contained in the access ticket to ensure authenticity of the information.
For example, if the channel object and the access ticket specify a particular broadcast channel, or a particular multicast channel such as an Mbone channel, and specify a particular time period, the client computer will receive the information transmitted asynchronously by the information source computer to many client computers over the broadcast or multicast channel during that time period. The client computer filters the contents of the broadcast or multicast channel according to specifications derived from the access ticket. For example, the access ticket may specify that the information to be received by the client computer begins with a specific character or code that identifies the supplier of the information, its rating, or the content of the information. In addition, the access ticket may require the client computer to search for a specific keyword in the information, such as "BUGS BUNNY," before accepting the information.
Alternatively, if the channel object and the access ticket simply specify a particular supplier of information on the computer network, the client computer will receive information transmitted by the information source computer to the client computer over the computer network at any arbitrary time. The access ticket may specify a limit on the time during which the information
source computer is allowed to transmit information to the client computer. This time limit may originate from the channel object, and, in addition, the client computer may be programmed to allow the user to preset time limits on access tickets.
One specific implementation of an access control list is the use of a notification server that acts as a filtering mail gateway. The notification server, acting on behalf of the client computer, receives e-mail messages only from information source computers specified on the access control list. In other implementations the notification server is a file service operated by an internet service provider, or a part of the information systems department of a company that includes the client computer.
In another specific implementation the document containing the channel object that is transmitted by the server computer to the client computer specifies that the information from the information source computer will be encrypted, and that a key will be transmitted by the server computer to the user computer to decrypt the information upon the user paying a fee specified in the document. As an alternative, the user may be charged for use of the information from the information source computer according to the metering technique described below in connection with Figs. 7 and 8.
The client computer is programmed to permit the user to inquire which access tickets are in the user's access control list and to display the icons corresponding to each of the access tickets. These icons are included in the channel objects received by the client computer.
Channel objects may be embedded not only in documents or pages on the World Wide Web, but in an alternative implementation they may be embedded in e-mail
messages, OLE objects, ActiveX applets, etc. In fact, all of the communications between the server computer and the client computer and between the information source computer and the client computer may occur by e-mail, via compound documents, etc.
Referring to Fig. 3, another network-based system for controlled transfer of information includes a client computer 100, operated by a user, a coupon-providing server 102 that transmits a document to the client computer containing a coupon 104, and an offer-providing server 106 that transmits a document to the client computer containing or corresponding to a smart digital offer object 108 that calculates an offer based on the coupon 104 and on other information stored at the client computer. Offer-providing server 106 or optional intermediary server 111 may verify the information stored at the client computer on which the offer is based. The client computer 100 may store coupons 104 in coupon registry 110. Referring to Figs. 4A and 4B, in operation of the network-based system of Fig. 3, the coupon-providing server sends a document to the client computer containing an embedded digital coupon (step 112) . The coupon may be an executable program or program fragment expressed in machine-executable form, such as an ActiveX applet, and protected against unauthorized tampering by means of an authenticator such as a digital signature or MAC code (Message Authentication Code) , or the coupon may be a digitally signed set of inputs to a program already residing at the client computer. The coupon contains a set of restrictions such as an expiration date, a product code or item number, and a discount amount. Alternatively, the coupon may simply contain a coded number that can be understood by the smart digital offer object described below.
The client computer retrieves the digital coupon from the document and stores it either in a coupon registry or separately (step 114) . The client computer is programmed to periodically remind the user of the special rights or capabilities that possession of the coupon provides to the user, including the coupon's expiration date, using known methods such as pop-up windows and audiovisual prompts (step 116) . The coupon may also contain a URL that is displayed to the user and on which a user can click to go to an offer-providing computer (a "store") that markets the product corresponding to the coupon as well as other products. Thus, the coupon acts as an advertising technique.
In one embodiment the coupon registry at the client computer is a purchasing history and the coupons are digital receipts identifying products purchased, dates of purchase, and possibly prices paid, together with authenticators of the digital receipts. The digital receipts function in the same manner as ordinary coupons because they will be used for the purpose of offering an adjusted price (typically a discounted price) to the user of the client computer. These digital receipts are transmitted from a server to the client computer together with authenticators upon completion of a purchase transaction.
The client computer fetches a document of web- based information from the offer-providing server that contains a smart digital offer object (step 118) . The smart digital offer object may be an executable program or program fragment expressed in machine-executable form, such as an ActiveX applet, and protected against unauthorized tampering by means of an authenticator such as a digital signature or MAC code, or the smart digital offer object may be a digitally signed set of inputs to a program already residing at the client computer. The
smart digital offer object received by the client computer may be protected against unauthorized tampering by means of a digital signature or MAC code. In an alternative embodiment the smart digital offer object remains at the offer providing server and need not be protected against tampering. The client computer activates the smart digital offer object (step 120) , and the smart digital offer object attempts to observe the parameters of the execution environment at the client machine, including the presence of coupons, and possibly other information such as a purchasing history recorded on the client computer.
If the smart digital offer object attempts to observe the purchasing history or certain other user- specific information, the client computer asks the user whether the user wishes to reveal the information (step 122) . The user indicates whether release of the information is authorized (step 124) , and the smart digital offer object then examines the coupon (including the coupon's authenticator) , digital receipts (including authenticators) and other user-specific information authorized to be revealed by the user, and presents to the user an offer of a product or service (step 126) . The execution environment at the client computer can under some circumstances change between steps 118 and 126. For example, the client computer may receive a coupon after step 118 occurs but before step 126 occurs. In one particular embodiment the client computer includes a client "avatar" of the type described below in connection with Figs. 5 and 6, which limits the release of certain information only to trusted servers, or only upon authorization from the client user, or both.
The terms or conditions of the offer, such as price and payment terms, are calculated by the smart digital offer object using formulas that depend on the
information contained in the digital coupons and the other information examined by the smart digital offer object, including the time of day, or user profile information such as membership codes, user's age, user's income, and other demographic information certified by an independent authority with an authenticator. When the user accepts the offer (step 128) the client computer sends a message to the offer-providing server indicating that the user has accepted the offer, or sends the message to an intermediary server that is trusted by the client computer to maintain the confidentiality of user- specific information and is trusted by the offer- providing server to verify the terms on which the offer was accepted (step 130) . The message sent to the offer- providing server or the intermediary server includes the terms upon which the offer was accepted and also includes an authenticator. The offer-providing server or the intermediary server verifies the terms on which the offer was accepted by verifying the authenticator (step 132) , and, if an intermediary server is used, the intermediary server reports the acceptance of the offer and the terms on which it was accepted to the offer-providing server. The offer-providing server then fulfills the offer by causing the offered product or service to be provided to the user (step 134) .
The calculations of the terms and conditions of the offer may be performed in a smart card or other tamper-proof device on the client computer that is trusted by the offer-providing server. The smart card validates the smart digital offer object and the coupons and other signed information used by the smart digital offer object. If theses items are valid, the smart card calculates the terms and conditions of the offer based on the program fragments or parameters contained in the smart digital offer object, the coupon or coupons, and
the other information examined by the smart digital offer object. The smart card computes and signs a digest of the smart digital offer object, its inputs, and the terms and conditions calculated by the smart digital offer object. The client computer communicates this signed digest back to the offer-providing server with the acceptance message to be used as the authenticator. The acceptance message includes the terms and conditions of the offer. The smart card contains a secret key "K" that is used to create the signed digest. "K" is never released outside of the smart card. The smart card is designed to make it computationally infeasible to compute "K" even with possession of the device. The offer- providing server uses a signature checking key to check the authenticator.
Alternatively, the message sent by the client computer to the offer-providing server or the intermediary server indicating that the user has accepted the offer includes the smart digital offer object together with its authenticator, and it may also include the coupon and all other information examined by the smart digital offer object, together with authenticators (recall that coupons may include signatures) . This enables the offer-providing server, or the intermediary server (which functions as an equivalent of a smart card on the client computer) , to verify independently the authenticity of the smart digital offer object, as well as the authenticity of any information examined by the smart digital offer object that contains an authenticator such as a digital signature.
The coupon-providing server notifies the offer- providing server of the frequency of coupon distribution (step 136) , and the offer-providing server notifies the coupon-providing server of the frequency of offer completion (step 138) . This process makes it possible
for the coupon-providing and offer-providing servers to alter the terms of coupons and offers dynamically based on this information, possibly using complex control software. Specific examples of security techniques (e.g., smart cards, signature verification) useful in connection with the smart digital offer technique described above are provided in the above-mentioned U.S. Patent Application Serial No. 08/168,519. Specific examples of techniques for implementing objects such as the smart digital offer object and the coupons described above are described in Craig Brockschmidt, Inside OLE, second edition, Microsoft Press, 1995, and Adam Denning, OLE Controls Inside Out. Microsoft Press, 1995, the entire contents of which are hereby incorporated herein by reference.
An example of software code useful in implementing the smart digital offer pricing technique described above is attached hereto as Appendix A. Referring to Fig. 5, another network-based system for controlled transfer of information includes a client computer 200, a server computer 202 and an optional agency computer 204. Client computer 200 or agency computer 204 stores a client personal profile 206 containing demographic data, current shopping interests and preferences, contact addresses, and other personal or semi-personal information. The client personal profile can include information that changes on a day-to-day basis, such as a purchasing history (which may be recorded in accordance with the techniques described in the above-mentioned U.S. Patent Application Serial No. 08/08/328,133), or a list of goods that the user wishes to buy (entered manually by the user in response to a prompt) . Client computer 200 also stores a client security profile 208 that specifies that certain
information in client personal profile 206 should be disclosed to server computer 202 only to trusted servers or only upon authorization from the client user or both. A client "avatar" 210 located at client computer 200 acts as an agent for the user by controlling the release of information from client personal profile 206 to server computer 202.
Referring to Fig. 6, in operation of the network- based system of Fig. 5 the client computer obtains a document from the server computer that contains an offer/ catalog description record (step 212) corresponding to an offer or catalog that will be sent to the client computer. The offer/catalog description record contains a profile query specifying the kinds of profile information that will be useful to the server computer in constructing a client-specific offer or in dynamically customizing the content of a catalog to be transmitted to the client computer. The offer/catalog description record also identifies the supplier of the record and the server computer to which the profile information should be sent, and contains the supplier's authenticating signature. Receipt of the offer/catalog description record by the client computer activates the client avatar (step 214) . The client avatar compare the profile query in the offer/catalog description record with the security profile, which restricts the domain of profile information against which the profile query is processed (step 216) .
If the profile query requests information that the security profile restricts only to trusted servers, then the client avatar determines whether the server computer is one of the trusted servers and, if so, checks the authenticating signature contained in the offer/catalog description record (step 217) (the client avatar may assume that if the supplier of the record is a trusted
supplier, then the server should be trusted too) . If the profile query requests information that, according to the security profile, requires user authorization for release, then the client avatar prompts the user for authorization to release the information to the server computer (step 218) and the user indicates whether release of the information is authorized (step 220) . Ordinarily, the user will not be prompted for authorization to release information to a trusted server, but the security profile can nevertheless be configured to require this for certain information.
After the client avatar determines which requested information can be released to the server computer, the client avatar transmits a subset of the client personal profile to the server computer, or sends an authorization message to the agency computer, which in turn transmits the subset of the client personal profile to the server computer (step 222) . The subset includes all information in the client personal profile requested in the profile query and authorized for release to the server computer. Thus, the subset may not include all the information requested in the profile query. The server computer then transmits a client-specific sales offer or a customized document such as an electronic newspaper or magazine to the client computer based on the subset of the client personal profile received by the server computer (step 224) , and the offer or document is displayed to the user at the client computer. The server computer may use the subset of the client personal profile to customize other web-based services offered to the user, including digital coupons, search services, and advertisements. Client- specific sales offers and coupons can be implemented in accordance with the smart digital offer technique described above in connection with Figs. 3 and 4A-4B. The server computer could alternatively use the subset of
the client personal profile to select or fabricate a channel object to send to the client computer, the channel object corresponding to a channel for asynchronous transfer of information to the client computer. The client computer can then activate the channel object in accordance with the technique described above in connection with Figs. 1 and 2. The server computer may even create a broadcast or multicast channel for the user by broadcasting or multicasting client- specific information and placing a specific identifying character or code at the beginning of the client-specific information. All of this can be accomplished using a single client personal profile stored at the client computer or agency computer, rather than multiple personal profiles stored at multiple server computers.
The security profile of the user can be developed progressively according to a scheme in which the security profile initially assumes that every supplier of offer/catalog description records is untrusted, every server is untrusted, and all information requires user authorization for release to every server. As profile queries are received by the client avatar, the client avatar queries the user whether the server computer should be trusted in the future (or whether the supplier of the offer/catalog description records should be trusted in the future, in which case the servers used by the trusted suppliers will be trusted too) , and whether the requested information is authorized for release to untrusted servers. Based on the user's responses, the client avatar appropriately reconfigures the security profile.
In one embodiment, when the client avatar sends the subset of the client personal profile to the server computer, the client computer identifies the agency computer to the server computer. At the same time the
client avatar sends an authorization message to the agency computer authorizing release of certain information, or any and all information, from the client personal profile to the server computer. This allows the server computer to transmit profile queries to the agency computer and to receive from the agency computer subsets of the client personal profile, even when the client computer is off-line. The agency computer maintains an access control list corresponding to all of the authorization messages received from the client computer, so that the agency computer can know which information can be released to which servers.
Referring to Fig. 7, another network-based system for controlled transfer of information includes a client computer 300 that contains a metering log 302 for counting the number of times client computer 300 accesses certain information, a server computer 304 that provides documents to client computer 300, and an optional agency computer 306 that stores billing records 308 corresponding to the client computer's access to information.
Referring to Fig. 8, in operation of the network- based system of Fig. 7 the client computer first obtains valuable web-based information (step 310) in the form of a document containing an embedded active link that retrieves additional information and also implements a small program or applet. The active link may be embedded in the document by means of the known technique of ActiveX Controls. The client computer displays the document (step 312) . When a user clicks on a representation of the active link (step 314) or, in an alternative embodiment described in detail below, when the active link is called by the browser at the client computer (step 316) , the client computer activates the active link (step 318) . Activation of the active link at
the client computer includes activation of the applet (step 320) , which may fetch from the server computer, or elsewhere, a machine-executable program that is used for client-side metering of the end-user's access to valuable web-based information, as is explained below. The client computer may store the machine-executable program after it is first retrieved, so that subsequent activations of the applet do not require communication with another computer to obtain the program. Activation of the applet causes the client computer to record in the metering log the fact that a certain document, or a certain portion of the document, has been displayed (step 322) .
The embedded active link may be a hyperlink that permits a user to navigate easily among documents by allowing the user to activate a hyperlink in a first document to obtain a second document, thereby making information contained in the documents readily accessible to the user. The retrieval of the second document can be implemented by the same applet that is used for the metering function. This can discourage disabling of or tampering with the metering function, especially if the embedded hyperlinks in a collection of documents are central to the utility of the collection of documents. In particular, the active hyperlink can check for the presence of a working metering log on the client computer before a second document is retrieved.
Other techniques for discouraging tampering could also be used. For example, the applet could fetch a program having a name that is changed on a frequent basis, where the scheme for changing the name is known only to the applet and where the applet is inoperable without the use of the program.
In certain embodiments the applet can use some or all of the techniques described above in connection with Figs. 3 and 4 to check for licenses, coupons,
subscription records, or access tickets in order to determine 1) whether to get a second document 2) which document to get, and/or 3) what information to record in the metering log. As has been mentioned above, in certain embodiments the embedded active link is activated whenever it is called by a browser (step 316) . In these embodiments the active link is a data record or tag record that automatically causes an embedded image to be retrieved and displayed at a certain location on the document. The applet is activated, and hence the metering function is activated, whenever the active link is initialized (i.e., whenever the document is displayed) , or alternatively whenever the embedded image is displayed (i.e., whenever a certain portion of the document is displayed during a display refresh) . The display of the embedded image can be implemented by the same applet that is used for the metering function, in order to discourage tampering with the metering function. The embedded image may be transparent, in which case the sole practical function of the activation of the active link is to cause the client computer to activate the applet for metering of the user's access to information. The applet may record click activity on the transparent embedded image and then pass the click activity on to other objects in the document, thereby capturing detailed usage information that is stored in the metering log, such as the number and location of clicks. Because the active link is associated with an image (albeit a transparent image) the browser will not ignore it when the location of the transparent image is re-displayed.
In certain embodiments the applet described above is inoperable unless the active link that implements the applet includes a cryptographic validation signature.
This scheme ensures that the active links can be inserted into documents only by licensed authors.
The client computer periodically transmits the contents of the metering log to the server computer, or alternatively to the agency computer (step 324) . If the contents of the metering log are transmitted to the agency computer, the agency computer enters the information contained in the metering log into detailed billing records, which may be records for a single client computer or many client computers, and the agency computer periodically transmits these billing records to the server computer. When the client computer accesses particularly valuable information the applet activated by the client computer may require the client computer to transmit the contents of the metering log immediately in order to prevent the client user from re-initializing the client computer and erasing its metering logs.
The information obtained from the metering log may be used solely for advertising feedback purposes, without any charges to the user. For example, the agency computer may be operated by an advertiser that is charged by the server computer on a per-usage basis whenever client computers display portions of documents on which advertisements are displayed. The client computer sends metering log information to the server computer and also to the agency computer so that the agency computer can know that the server computer has not tampered with the information.
There have been described novel and improved apparatus and techniques for controlled transfer of information in computer networks. It is evident that those skilled in the art may now make numerous uses and modifications of and departures from the specific embodiment described herein without departing from the inventive concept.
δcϊ 29 1996 16:06:20 ^ ι. f CouponPpg cpp Pagel Oct 29199616:06:20 CoϋponPpg.cpp Page 2
// CouponPpg cpp : Implementation of the CCouponPropPage property page class DDX_Text(pDX. IDC_EDIT1, m_StoreID) ,
DDP_Text(pDX. IDC_EDIT2, m_UniqueID, _ I 'UniquelD' ) );
Iinclude 'stdafx.h' DDX_Text(pDX. IDC_EDIT2, m_UnlqueID) , Iinclude "coupon. h" DDP_Text(pDX. IDC_EDIT1, m_DiscountRate, _T( "DiscountRate" ) ), Iinclude 'CouponPpg h" DDX_Text(pDX, IDC_EDIT3, m_DiscountRate) ; DDV_MinMaxDouble(pDX, . DiscountRate, 0., 1.): llfdef _DEBUG DDP_Text(pDX, IDC_EDIT4, m_DlacountAmount, _T( "DiscountAmount* ) ■define new DEBUG NEW DDX.TextlpDX. IDC_EDIT4, m_Dl»countAmount) ;
9 lundef THIS_riLE //))AFX_DATA_HAP
10 static char THIS_FILE(] = FILE__, DDP_PostProcessing (pDX) ,
11 lendif
12
13
14 IHPI.EMENT_DYNCREATE (CCouponPropPage. COlePropertyPage)
15 II CCouponPropPage message handlers
16
17
18 II Message map
19
20 BEGIN_MESSAGE_MAP(CCouponPropPage, COlePropertyPage)
21 //((AFX_MSG_HAP (CCouponPropPage)
22 // NOTE - Class izard will add and remove message map entries
23 // DO NOT EDIT what you see in these blocks of generated code '
24 //))AFX_MSG_MAP
25 FHD_MESSAGE_MAPO
26
27
28
29 I I Initialize class factory and guid
30
31 IMPLEMENT_OLECREATE EXI CouponPropPage, "COUPON CouponPropPage 1".
32 0xebf68c64. 0x234a, OxlldO. OxaO, 0x21, 0x44, 0x45, 0x53. 0x54. 0, 01
33
34
35
36 I I CCouponPropPage :CCouponPropPageFactory :UpdateRegistry -
37 // Adds or removes system registry entries for CCouponPropPage
38
39 BOOL CCouponPropPage: -CCouponPropPageFactory UpdateRegi stry (BOOL bRegister)
40 (
41 if (bRegister)
42 return AfxOleRe isterPropertyPageClass (AfxGe InstanceHaπdlel ) .
43 m_clsld. IDS_COUPON_PPG) ;
44 else
45 return A xOleUnregisterClass (m_clsld, NULL),
46 )
47
4B
49
50 II CCouponPropPage: :CCouponPropPage - Constructor
51
52 CCouponPropPage- :CCouponPropPage O ■
53 COlePropertyPage (IDD, IDS_COUPON_PPG_CAPTIONI
54
55 //((AFX_DATA_INIT(CCouponPropPage)
56 m_StoreID - _T(") ;
57 m UniqueID ■ _T(");
58 tn_DiscountRate * 0.0,
59 m_DiscountAmount ■ 0 0,
60 //))AFX_DATA_INIT
61
62
63
64 ni i ii/ni/iiii IIII mm im nn ii ni mil inn mi ii ni i n ii
65 II CCouponPropPage: :DoDataExchange - Hoves data between page and properties
66
67 void CCouponPropPage- :DoDataExchange(CDataExchange" pDX)
68 (
69 //t(AFX_DATA_HAP(CCouponPropPage)
70 DDP_Text(pDX, IDC_EDIT1. m_StorβID, _T("StorelD") ) ;
10
11
Oct!29199616:06:22 f !' > coupon.h Page 1
// coupon.h : main header file for COUPON.DLL
•if (defined! AFXCTL_H )
•error include 'afxctl.h' before including this file •endif
•include "resource. h" // main symbols
11 ni imimm imimm immiiii mmiiimiiii 11 ni 111111 ii 11 ii ii II II
I t CCouponApp : See coupon.cpp for implementation. class CCouponApp : public COleControlModule
( public:
BOOL Initlnstance!); int Exitlnstancel ) : ). extern const GUID CDECL _tlid: extern const WORD _wVerHajor: extern const WORD _wVerMinor; O O
J
12
13
14
15
16
17
18
20
21
22
23
24
25
26
-Oct 29199616:10:19 do.c Page 29 Oct 29 1996 16:10:19 do.c Page 30
1317 OSL_Statuβ WINAPI OSL_MakeServer(OSL_Server *server, OSL_Error "error, 1386
1318 OSL_Const_String scheme, OSL_Const_String host, int port, 1387
1319 OSL_Const_String script)
1320 ( 13B8
1321 OSL_ServerStruct "serverObj; 13B9 NAME
1322 int re « 0; 1390 OSL_FreeServer
1323 1391
1324 /• 1392 DESCRIPTION
132S * port number cannot be negative, zero is OK for default 1393 Free a server's memory when it is no longer needed
1326 •/ 1394
1327 if (port < 0) ( 1395 PARAMETERS
1328 re ■ OSLDO_E_INVALID_PORT; 1396
1329 error->status ■ re; 1397 OΞL_Server' server
1330 sprintf (error->mesεage, OS_Catgets (&OΞLDO_Meεsages , re), port), 1398 An input argument, passed by reference, the server to free
1331 return (re) ; 1399
1132 ) 1400 RETURN VALUES
1333 1401 None
1334 /• 1402
1335 • allocate memory 1403
1336 •/ 1404
1337 serverObj <= (OSL_ServerStruct •) malloc (sizeof (OΞL_ServerΞtruc )) , 1405 void WINAPI OSL_FreeServer(OSL_Server 'server)
133B if (serverObj =« NULL) ( 1406 I
1339 re - OSLDO_E_ALLOC_MEM; 1407 OSL_ServerStruct 'ServerObj,
1340 error->status ■ re ; 1408
1141 sprintf (error->message, OS_Catgets (fcOSLDO_Messages rc l ) , 1409 if ( 'server =■ NULL ) return,
1342 return ( re ) , 1410 serverObj = (OSL_ServerStruct ') 'server,
1343 ) 1411
1344 1412 if ( serverObj ->scheme ) free (serverObj->scheme) ;
1345 1413 if ( serverObj->hoεt ) free (serverObj->host) ;
1346 assign scheme 1414 if ( serverObj->script ϊ free (serverObj->scrlpt) ;
1347 1415 ree (serverObj ) ;
1348 if (scheme == NULL |j strlen(scheme) == 0) ( 1416 'server = NULL;
1349 serverOb ->scheme = strdυ ( "http' ) , 1417 return;
1350 ) else ( 1418
1351 if ( strcmp(scheme, "http") != 0 && strcmplscheme, "https") '= 0 ) ( 1419
1352 re = OSLD0_E_WRONG_SCHEME;
1353 sprintf(error->message. OS_Catgets (-OSLDO_Mesεages. re) scheme),
1354 error->statuε ■ re,
1355 free (serverObj ) ,
1356 return (re) ;
1357 ) else (
1358 serverObj ->scheme = strdup I scheme ) ,
1359 1
1160
1361
1362
1363 assign host
1364
1365 if (host '= NULL) serverObj ->host strdup(host) ,
1366 else serverObj->host = HULL;
1367
1368
1369 * assign port
1370 •/
1371 if (port I- 0) serverObj ->port ■ port;
1372 else if (βtrcmp(serverObj->scheme, "https") == 0) εerverObj->port = 443;
1373 else serverObj->port ■ 80;
1374
1175 /•
1176 * assign cgi script
1377 •/
137B if (script !- NULL) serverObj ->εcript - strdup(script) .
1379 elεe serverObj->script ■ NULL;
1380
1381 'server - (OSL_Server ) serverObj,
1382
13B3 return ( 0 ) ;
1384
1385
27
28
tθct 29 1996 16:10:19 'H* do.c Page 33 Oct 291996 16:10:19 do.c Page 34
1551 1589 1552 1590 1S53 • copy the content server 1554 •/ 1591
1555 if (rc«OSL_CopyServer( (OSL_Server •) HstoreObj->contentServer) . error, 1592 NAME 15S6 contentServer)) goto ErrorMakeStore; 1S93 OSL_FreeStore 1557 1594 1558 /• 1595 DESCRIPTION 1559 • copy the Fulfillment server 1596 Delete a store when it is no longer needed. 1560 •/ 1597 1561 /' defaults to content server '/ 1598 PARAMETERS 1562 if ( ful illmentServer =■ NULL) fulf llmentServer ■ contentServer; 1599 1563 1600 OSL_store* store 1564 if (rc*OSL_CαpyServe ( (OSL_Server *) _ (StoreObj->fulfillmentServer) , error , 1601 An input argument, passed by reference, the store to delete 1565 ful illmentServer) ) goto ErrorMakeStore; 1602 1566 1603 RETURN VALUES 1567 /• 1604 None 1568 • copy the key 1605 1569 '/ 1606 1570 if (re * OΞL_CopyKey( (0SL_Key ') & (storeObj->key) , error, key ) ) 1607 O 1571 goto ErrorMakeStore; 1608 void WINAPI OSL_FreeStore(OSL_Store 'store] 1572 1609 ( 1573 1610 OSL_ΞtoreStruct "storeObj, 1574 • give the store ID 1611 1575 "/ 1612 if ( 'store == NULL ) return; 1576 storeOb ->storeID a strdup (storelD) , 1613 storeObj = (OSL_StoreS ruct *) 'store; 1577 1614 1578 /• 1615 OΞL_FreeServer ( (OSL^Server ') f< ( storeOb ->transactServer ) ); 1579 * set the output 1616 OSL_FreeServer( (OSL^Server •) -( StoreObj->ful illmentServer ) ); 1580 */ 1617 OSL_FreeServer ( (OSL_Server ■) C, ( storeOb ->contentServer ) ); 15B1 •store => (OSL_Store) storeObj, 1618 OSL_FreeServer( (OSL_Server ') storeObj->subscriptionServer ) ); 1582 return (0) ; 1619 OSL_FreeKey( (0SL_Key •) .( storeObj->key ) ); 15B3 1620 if (storeObj ->storeID) free (storeObj->storeID) . 1SB4 ErrorMakeStore: 1621 free (storeObj ) ; 1585 OSL^FreeStore ( (OΞL_Store •) -storeObj), 1622 •store = NULL; 1586 return (re) ; 1623 return; 1587 1624 1588 1625 1626
29
30
31
32
33
34
35
Oct 29199616:10:49 mdSc.c Page 3 Oct 29199616:10:49 mdSc.c Page 4
141 operation processing another message block, and updating the 211
142 context 212 /• HD5 basic transformation Transforms state based on block
143 •/ 211 •/
144 void OH_HD5Update lcontext input. inputLen) 214 static void 0M_MD5Transform (state block)
145 MDS.CTIC "context, /" context 215 UINT4 stateMI:
146 unsigned char *input; /• input block 216 unsigned char block(64],
147 unsigned int InputLen; /• length of nput block 217 (
148 ( 218 UINT4 a « statetO], b = state[l], c - state[2]. d state[3], x(16).
149 unsigned int i, index, partLen, 219
150 220 OM_Decode (x. block 64)
151 /• Compute number of bytes mod 64 */ 221
152 index = (unsigned Int) ( (context->count [0 J >> 3) & 0x3F) , 222 /• Round 1 •/
153 223 FF (a. b c. d. xi 01, sii, 0xd76aa478] ; 1 •
154 /* Update number of bits */ 224 FF (d, a. b. c. xl II. S12. 0xe8c7b756) ; 2 •
155 if l(context->count[θj *- I IUINT4) inputLen << 3)1 225 FF (c. d. a. b. xl 2|. S13. 0x242070db); 3 •
156 < (IU1NT4) InputLen <:< 3)1 226 FF (b. c, d. a. x[ 3], S14, Oxclbdceee) ; 4 •
157 context->coun [1J ++; 227 FF (a. b. c, d, x! 4). Sll. 0x£57c0fafl : 5 •
1S8 context->count[l] *■«= I (UINT ) inputLen >> 29), 228 FF (d. a. b, c. xl 51. S12, 0x47B7c62a). 6 •
1S9 229 FF (c. d. a, b. xt 6). S13. 0xa3304613); 7 • 0 160 partLen = 64 - index, 230 FF (b, c. d. a, χ[ 71. S14, 0xfd469501) . 8 •
161 231 FF (a, b. χ| β], Sll. 0x698098331 , 9 '
162 /* Transftrm as many timos s ssible 232 FF (d, a, b. c, xl 91, S12, 0x8b44f7afl , 10 O 163 '/ 233 FF (c, d. a, b. x[101. S13, 0xfff£5bbl), 11 ) 164 if (inputLen >= partLen) ( 234 FF lb. c, d, a, xllU. S14. 0x895cd7be), 12
165 OM MD5_memcpy 235 FF (a. b. c, d. x|12), Sll. 0x6b901122) , 13
166 TlPOINTER)".context->bu£fer[ιndexl , (POINTER) input, partLen), 236 FF (d, a. b. c, xtl31. S12. 0xfd987193). 14
167 OM_MD5Transform lcontext->state, context->buffer) ; 237 FF Ic, d, a, b, XI141. S13. 0xa679438e): 15
168 238 FF lb, c. d, a x[15). S14, 0x49b40821) . 16
169 for (i * partLen; i ♦ 63 < inputLen; i +■ 64) 239
170 0l!_MD5Transfor (context >state Cinput(l)) 240 /• Round 2
171 241 GG (a, b. χ[ H. S21 0xf61e2562) , 17 n 172 index = 0, 242 GG Id, a, xl 6]. S22. 0xc040b340), IB
173 ) 243 GG (c. d xlill. S23. 0x265e5a51); 19
174 else 244 GG (b, c χ| 01. S24. 0xe9b6c7aa) ; 20
175 i = 0 245 GG (a, b. xt 5). Ξ21, 0xd62fl05d) ; 21
176 246 GG Id, a xlioi, S22. 0x24414531. 22
177 /" Buffer remaining input •/ 247 GG Ic, d x|151. S23, 0xdBale681) . 23
178 0M_MD5_memcpy 248 GG lb, c, xl 41, S24. 0xe7d3fbc8] . 24
179 I (POINTER)(.context->buffer I index] IPOINTER) I,input [ 1 ] 249 GG [a. b. x| 91, S21. 0x21elcde6) : 25
1B0 InputLen- i ) , 250 GG (d. a. "•[141. S22, 0xc33707d6) . 26
181 ) 251 GG (c, d. xl 31. S23, 0xf4d50dB7| , 27 - 182 252 GG lb. c, xl 8], S24. Ox455al4ed) . 28
183 ' IID f nali-atlon Ends an MD5 message-digest operation writ nn t) 253 GG (a, b, χ|i31, S21, 0xa9e3e905). 29
184 the message diqest and zeroizing the context 254 GG Id a, x| 21. S22, 0xfcefa3fS) , 30
1B5 •/ 255 GG |c, d, x[ 71. S23, 0x676f02d9) ; 31
186 void OM_MD5Final (digest, context) 256 GG lb, c x[12J. S24, 0x8d2a4c8a] , 32
187 unsigned char digest[16], /* message digest '/ 257
188 MDS_CTX "context. /' context */ 258 /* Round 3
189 ( 259 HH (a, b c x[ 5], S31, 0xf£fa3942), 33
190 unsigned char bιts[8), 260 HH (d, a. b x[ 81. S32, 0xβ771f681l. 34
191 unsigned int index, padLen, 261 HH (c, d, a xllll. S33, 0x6d9d6122l; 35
192 262 HH lb. x[141, S34, 0xfde5380c) ; 36
193 /" Save number of bits •/ 263 KM la, χi n . S31, 0xa4beea44) ; 37
194 OM Encode (bits, context->couπt , 8), 264 HH (d, b. x| 41, S32, 0x4bdecfa9) ; 38
195 265 HH (c, χ| 71. S33. 0xf6bb4b60) ; 39
196 /' Pad out to S6 mod 64 266 HH (b, c, d, a, xlioi. S34. 0xbebfbc70); 40
197 •/ 267 HH (a, b, c. d, XU31, S31, 0x289b7ec6); 41
198 index = (unsigned in ) ( (context->count [01 >> 3) fc 0x3f), 268 HH [d. a. b. c. x[ 0). S32. 0xeaal27fa) : 42
199 padLen - (index < 56) ? (56 - index) : (120 - index); 269 HH (c, d, a. b, xt 31, S33, 0xd4ef3085] ; 43
200 0M_MD5Update (context, OM_PADDING, padLen); 270 HH (b. c. d, a, χ| 61. S34, 0x4881d05); 44
201 271 HH (a, b. c, d, l 9|. S31, 0xd9d4d039); 45
202 /* Append length (before padding) '/ 272 HH (d, a, b, c, x[121. S32. 0xβ6db99e5)ι 46
201 OM MDSUpdate (context, bits, 81, 273 HH (c, d, a. b, x[15], S33. 0xlfa27cfβlι 47
204 /• Store state in digest '/ 274 HH lb, c. d. a, xt 21. S34. 0xc4ac5665); 48
205 OM„Encode (digest, context->state 16), 375
206 276 /• Round 4 •/
207 /• Zeroize sensitive information 277 II (a. b. c, d, xl 01. 541. 0xf4292244); /" 49 •/
208 •/ 278 tl Id. a. b, c, l 7|. 542. 0x432aff97)| /• SO •/
209 OM_MDS_memset I (POINTER)context, 0. sizeof ("context)); 279 II (e. d, a. b. Xtl4), 543, 0xab9423a7|| /• SI •/
210 280 II (b, c, d, a. l 51. 544, 0xfc93a039); /• 52 •/
36
37
38
Oct 29 199616:42:37 -fcffij 1, ■ ■ ,' ■: ' ■ OmdOCtl.Cpp ■VK-! Page7- "Oct29199616:42:37 omdoctl.cpp Page 8
407
408 //
409 PX.String (pPX, _T ( "UniquelO") , m_UniqueID. _TC")
410 if ( pPX -> IsLoadin (I )
411
412 SetUnlquelD ( UniquelD );
413
414
415 (
416 PX.String (pPX, _T ('Detail"). m_URL = m_err message;
417 if I pPX -> IsLoading!) ) ) else (
418 //m_URL.ReleaseBuffer( I ;
419 SetDetail (m_Detail I; orgBuf = m_URL;
420 encBuf = radix64encode_noslash ( (char 'I orgBuf. strlen
421
432 m_URL * encBuf;
423 PX.String (pPX. _T ( "OfferURL" ) . m_OfferURL, freet (void *l encBuf)
424 If ( pPX -> IsLoading!) ) //isCreated = 1;
425
426 SetofferURL (m_offerURL );
427 m_URL ReleaseBufferd , ) 428
429 0 430 PX_Strinς IpPX. _T ("Type"). m.Type. _TC
431 if ( pPX -> IsLoading!) I PX_String (pPX, _T CURL"). m_UR . _TC"I );
432 if ( pPX -> IsLoading!) I
433 SetType( .Type) (
434
435 )
436 PX_String (pPX, _T ("Opera ion"), m_Operation, _T (" " ) ),
437 if ( pPX -> IsLoading!) )
438
439 SetOpera ion (m_Opera ion) ,
440
441
442 PX_String (pPX, _T ("Price") m_Price,
443 if ( pPX -> IsLoading!) )
444
445 SetPrice (m_Price) ;
446
447
448 PX_String (pPX, _T ("Curiency ), ^Currency.
449 if I pPX -> IsLoading!) )
450
451 'SptCurrenry ( Curiency) ,
452 11111111111111111111111111111111111111111111111111111111 ni 111111111111111111
453
454
455 if ( ( IpPX -> IsLoading () I S.E. isCreated = 0)
456
457 OSL_SetOfferCell (m_offer, im_err, "Name", OSL_Column_value,
458 m_ProdName. 0) ;
459 OSL_SetOfferCell (m_offer, tm_err, "Price", OSL_Coluιnπ_value,
460 m_Price, 0} ; 461 OΞL_SetOfferCell (m^offer, tm_err, •UniquelD". OSL_Columπ_val
462 m^UniquelD, 0) ; 463 OSL_SetOf erCell (m_offer, &m_err, "Detail", OSL_Column_value (
464 m_Detail, 0);
465 OSL_Ξetof erCell (m^offer. £.m_err, •OfferURL". OSL„Column_val
466 m_0fferUR , 0); 467 OSL_SetOfferCell (m_offer. (.m_err, "Type*. OSL_Column_value, 46B m^Tv e. 0) ; ( 469 OSL_SetOfferCell (m_o£fer. -m_err, "Operation", OSL_Column_va m_ProdName - IpsiNewValue;
470 m Dperation. 0) ; SetHodifiedFla l) : 471 OSL_SetOfferCell [m_offer, fc*n_err. "Currency", OSL_Colurnn_val
;Oct 29 1996 16:42:37 , '''*' " ' ■ ' '< J Omtjoctjicpp ' &.'% 'Page 9- Oct 29199616:42:37 omdoctl.cpp Page 10
539 609 m_Price • IpszNewValue;
540 BSTR COmdoCtrl: :GetUniqueID() 610
541 611 SetHodifiedFlag!) ;
542 return m_UniqueID. AllocSysString [ ) ; 612
543 613
544 614 BSTR COmdoCtrl: :GetCurrency ! )
545 void COmdoCtrl: : SetUniquelDlLPCTSTR IpszNewValue) 615 (
546 616
547 m_UnlqueID ■ IpszNewValue; 617 return m_Currency. AllocSysStrin [ )
548 SetHodi ledFlagl) ; 618
S49 619
550 620 void COmdoCtrl : : SetCurrency ( LPCTSTR IpszNewValue)
551 BSTR COmdoCtrl: :CetDetail() 621 !
552 622
553 return m_Detail .AllocSysS ring ( ) ; 623 m_Currency * IpszNewValue;
554 624
555 625 SetHodifiedFlag!) ;
556 ■oid COmdoCtrl :: SetDetaiHLPCTSTR IpszNewValue) 626
557 627
558 m_Detall = IpszNewValue: 628 BSTR COmdoCtrl: :GetPdoSSI()
559 SetModifledFlagO ; 629 (
560 630 3 561 631 return m_PdoSΞI AllocSysString!);
562 ΪSTR COmdoCtrl: : GetOfferUR ( ) 632
563 633
564 return m_0fferURL.AllocSysString! ) ; 634 void COmdoCtrl: :SetPdoSSI (LPCTSTR IpszNewValue)
565 635
566 636
567 /oid COmdoCtrl: •SetOfferURLILPCTSTR IpszNewValue! 637 m_PdoSSI « IpszNewValue;
568 638 SetHodif iedFlagl) .
569 m_OfferURL ■ IpszNewValue; 639
570 SetHodifiedFlag! I ; 640
571 641 BSTR COmdoCtrl: :GetURL()
572 642 1
573 643 return m_URL .Al locSysS rin ! ) ;
574 ΪSTR COmdoCtrl GetOperation ( ϊ 644
575 645
576 646 void COmdoCtrl : -SetUR fLPCTSTR IpszNewValue)
577 return m^Operation.ΛllocSysStringl ) ; 647 (
578 648
579 649 m_URL = ipszNewVah
580 id COmdoCtrl ..-rOper,ιr l on { LPCTSTR IpszNewValue) 650 SetModi f iedFlag! ) ;
581 651
582 652
583 m^πperation = IpszNewValue; 653 void COmdoCtrl: :OnRButtonljown ( UINT nFlags, CPoint point )
584 654 (
585 SetHodif iedFlagl } ; 655 char msg[200) ;
586 656
587 657 if ( m_couponApplied)
5BS BSTR COmdoCtrl :GetType() 658
589 659 εprintf (msg. "A %d percent discount has been applied to this i
590 return m^Type .Al locSysString ( ) ; (int) (m_DiscountRate * 100.0 )):
591 660
592 661
593 3id COmdoCtrl: : SetType (LPCTSTR IpszNewValue) 662
594 663 sprintf (msg, "Ho coupon found for this item!");
595 m_Type = IpszNewValue; 664
596 665
597 SetHodif iedFlagl) ; 666 HesεageBoxEx(NULL, msg, "Smart Digital Offer",
598 667 HB_ICONEXCLAMATION|HB_OK, MAKELANGID(LANG_ENGLISH, SUB
599 LANG_ENGLISH_US) ! ;
600 BSTR COmdoCtrl: :GetPrice( I 66B
601 669
602 670
603 return m_Price.AllocSysStrin ( I ; 671
604 672 void COmdoCtrl: :OnLButtonDblclk(UINT nFlags, CPoint point)
605 673 (
606 id COmdoCtrl: :SetPrice(LPCTSTR IpszNewValue) 674
607 675
608 676 // TODO: Add your message handler code here and/or call default
) 0
10
Oct 29 1996 16:42:37 k l " όmdoppg.cpp Pagβ'1' Octf29199616:42:37 omdoppg.cpp Page 2
// OmdoPpg.cpp : Implementation of the COmdoPropPage property page class. 71 // AFX_DATλ_MΛP(COmdoPropPage) 72 DDP TextlpDX, IDC_EDIT1. m_ProdName, _T!*ProdName" )
■include "stdafx.h" 73 DDX TextlpDX. IDC_EDIT1. ProdNa e) : ■include "omdo.h" 74 DDP_Text(pDX. IDC_EDIT2. m JnicjuelD, _TI *UniqueID*) ■include "OmdoPpg h* 75 DDX_Text(pDX, IDC_EDIT2, π UnlquelD) ; 76 DDP_Text(pDX, IDC_EDIT3. _OfferURL, _TI "OfferURL" I I
■if ef .DEBUG 77 DDX_Text (pDX. IDC_EDIT3. m_0fferURLI : ■define new DEBUG_NEW 78 DDP_Text (pDX. IDC_EDIT4, .Detail, _TCDetail"l I;
9 ■undef THIS_FILE 79 DDX_Text(pDX. IDC_EDIT4. m_Detail) ;
10 static char THIS_FILE(] = FILE ; 80 DDP_CBString(pDX, IDC_C0HB02, m_Operation, _T(*Operation* I I;
11 •endif 81 DDX_CBStrtnglpDX. IDC_COHB02. _Operatlon| ;
12 82 DDP_CBStrIng(pDX. IDC_COHB01. m_Type, _TCType") 1;
13 83 DDX.CBStringlpDX. IDC_COMB01. m_Type);
14 IMP1.F.MENT_DYNCREATE (COmdoPropPage, COlePropertyPage) 84 //))AFX_DATA_MAP
15 85 DDP_PostProcessing(pDX) ;
16 86
17 87
IB I I Message map 88
19 B9 0 20 BEGIN_MESSAGE_MAP!COmdoPropPage, COlePropertyPage) 90 I t COmdoPropPage message handlers
21 //(<AFX_MSG_HΛP(COmdoPropPage)
22 // NOTE - ClassWizard will add and remove message map entries 3 23 // DO NOT EDIT what you see in these blocks of generated code ' ) 24 //))AFX_MSG_MAP
25 Er'D_MESSAGE_MAP{ )
26
27
28
29 II Initialize class factory and guid
30
31 IMP! F11EHT_0LECREATE_EX(COmdoPropPage, *0MD0 OmdoPrOpFage 1",
32 0x43b6bbc4. Oxlabb. OxlldO, OxaO, 0x21. 0x44. 0x45. 0x53. 0x54. 0, 01
33
34
35
36 I I COmdoPropPage. : COmdoPropPageFactory : ; UpdateRegistry -
37 // Adds or removes system registry entries for COmdoPropPage
38
39 BOOL COmdoPropPage. :C0mdoPropPageFactory UpdateReg istry (BOOL bPegistei)
40 (
41 if (bRegister)
42 return AfxOleReg isterPropertyPageCl s (Af Ge InstanceHandle( ) ,
43 m_clsld. IDS_0MD0_PPG) ;
44 else
45 return AfxOle nregisterClass !m_ lsιd, NULL), > 46
47
4B
49
SO I I COmdoPropPage: .COmdoPropPage - Constructor
51
52 COmdoPropPage: :COmdoPropPage ( I :
53 COlePropertyPage HDD. IDS_OMDO_PPG_CAPTION|
54
55 / / ( (AFX_DATA_INIT (COmdoPropPageI
56 m_ProdName »= _T(*'
57 m_UniqueID * _T(""
58 m_OfferURL =. .11"
59 m_Detail - _TI**I;
60 Ri_0peration ■ _T(*
61 m_Type = TI " " ) ;
62 //))AFX_DATA_INIT
63
64
65
66 11 i 1111111111111 π 11111111111111 : 11111111111111111111111111111111111111111111
67 I t COmdoPropPage: :DoDataExchange - Moves data between page and properties
68
69 void COmdoPropPage: :DoDataExchangβ(CDataExchanςβ* pDX)
70 I
11
Oct 29 1996 16:42:38 '.? , ; '. •' bmdoppg.h
1 // OmdoPpg.h : Declaration of the COmdoPropPage property page class.
1
3 1111111 ni 111 ni 11 m i ni ni 11111111111111111 m mm m 1111111111111111111 4 II COmdoPropPage : See OmdoPpg.cpp.cpp for implementation, 5
6 class COmdoPropPage : public COlePropertyPage
7
8 DECLARE_DYHCREATE(COmdoPropPage)
9 DECLARE_OLECREATE_E (COmdoPropPage)
10
11 // Constructor
12 public:
13 COmdoPropPage ( I ;
14
15 // Dialog Data
16 //((AFX_DATA(COmdoPropPage)
17 enum ( IDD ■ IDD_PROPPAGE_OMDO ) ,
18 CString m_ProdNaιtιe;
19 CString m_UniqueID;
20 CString m_OfferURL; ) 21 CString m_Detail;
22 CString m_Operation; 0 23 CString m_Type;
24 //))AFX_DATΛ n 25
26 // Implementation
27 protected:
28 virtual void DoDataExchangelCDataExchange* pDX); // DDX/DDV support
29
30 // Message maps
31 protected:
32 // ! (AFX_MSG|COmdoPropPage)
33 // NOTE - ClassWizard will add and remove member functions her
DO NOT EDIT what you see in these blocks of generated co
35 //))AFX_MSG 36 DECLARE_MESSAGE_MAP ( ) 37
38
12
13
iVoct 29 1996 16:42:38 •
'' i
■.**'': doiH for; 'Pβgβ-iϊr
' Oct 291996 16:42:38 ' pdo.h Page 2 i /* pdo.h Pre-Digital Offer API
2 65 3 Copyright !c) 1996 Open Market. Inc 66 /* Environment Definitions •/ 4 All rights reserved. 67 5 68 llf definedl_ IN32) || deflned(_HSC_VER)
6 This software contains proprietary and confidential information and 69 Iinclude <windows.h>
7 remains the unpublished property of Open Market. Inc. Use, disclosure, 70 ■else
8 or reproduction Is prohibited except as permitted by express written 71 Idefine WINAPI
9 license agreement with Open Market, Inc. 72 lendif
10 73
11 SIdi pdo h.v 1.3 1996/08/08 15:36:06 henry Exp S 74 •include <stdlib.h>
13 75
13 76 /* SecureLink Definitions */
14 liEndef PDO_H 77
15 Idefine PDO_H 7B •include "pdomsgs.h"
16 79
17 lifdef _cplusplus 80 llfndef OSL_MAX_MESSAGE ιa :xtern 81 Idefine OSL_MAX_MESSAGE 512
19 82 •endif 20 83 ) 21 84 lifndef FALSE 22 85 Idefine FALSE 0 B6 lendif
23 B7 24 Table of Contents 88 lifndef TRUE 25 89 Idefine TRUE 1 26 Definitions 90 lendif 27 91 28 Functions: 92 /• Offer Base Types •/ 29 OSL_HakeOffer 93 30 OSL_FreeOf fer 94 typedef char OSL_Char, 31 95 typedef char* OSL_String; 32 0SL_Make0 erFromFile 96 typedef const char* OSL_Const^Strιng; 33 OSL_MakeOfferFro String 97 typedef int OSL_Status: 34 OSL_LoadOfEerFromSSI 98 35 99 36 OSI._ rite0fferToFile 37 OSL_ rlteOfferTostring 100 38 OSL_ riteOfferToSSI 101 Offer Structure 39 102 40 OSL_SetOf ferHeaderValue 103 An OM-SecureLink SDK Offer is an opaque structure consisting of 41 OSL .GecOf ferHeaderValue 104 42 10S A "Header" composed of stru ture proper ies
43 OSL_SetOfferCell 106
44 OSL_GetOfferCell 107 A "Table" of Digital Offer IDO) attributes and associated information
45 OSL_RemoveOfferRow 108
46 109 Each "Row" of the table represents a single attribute.
47 OSL^GetO ferAttributes 110
48 OSL_Ge 0f ferRequiredA tr ibutes 111 The "Columns" hold the attribute properties (e.g.. name, value,
49 112 default value, constraint rules)
50 OSL_CheckOffer 113
51 OSL_CheckOfferValueType 114 The intersection of a Row and a Column is a "Cell" holding
52 OSL_Check0ffervalueRerjuired 115 a single property.
53 OSL_CheckOfferValueProhlbi ed 116
54 OSL_CheckOfferValueConstraints 117 An SDK Offer structure is constructed and modified as follows:
55 118
56 OSL_GetOfferMessage 119 1. Create an empty (null) Offer structure.
57 120 2. Fill in the Header properties.
58 121 Create a Row for each attribute, filling in the Cells one at a time. 122 Retrieve and/or modify any Cells.
59 123 Validate the Offer. 60 124 Generate a PDO (string) from an Offer. 125 Release/free the Offer and associated heap memory.
61 126 127 The SecureLink SDK functions perform one or more of these actions.
62 Offer Definitions 128 129
63
130
64 131 I ypedef void* OSL_offer;
15
16
17
18
19
Oct 29 1996 16:42:39 "-' .' *? • '''' ;• ■ Stdafx.cpp ifr,' Page 1 '
// stdafx cpp source file that includes just the standard includes
// stdafx pch will be the pre-compiled header
// stdafx obj will contain the pre-coπpiled type information
•Include "stdafx
ω c
0)
•H
•H
C •H m
H
~ o
20
21