US20130152165A1 - End user license agreements associated with messages - Google Patents

End user license agreements associated with messages Download PDF

Info

Publication number
US20130152165A1
US20130152165A1 US13/764,653 US201313764653A US2013152165A1 US 20130152165 A1 US20130152165 A1 US 20130152165A1 US 201313764653 A US201313764653 A US 201313764653A US 2013152165 A1 US2013152165 A1 US 2013152165A1
Authority
US
United States
Prior art keywords
message
computing device
end user
client computing
user license
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Abandoned
Application number
US13/764,653
Inventor
Mark Cameron Little
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Red Hat Inc
Original Assignee
Red Hat Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Red Hat Inc filed Critical Red Hat Inc
Priority to US13/764,653 priority Critical patent/US20130152165A1/en
Assigned to RED HAT, INC. reassignment RED HAT, INC. ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: LITTLE, MARK CAMERON, DR.
Publication of US20130152165A1 publication Critical patent/US20130152165A1/en
Abandoned legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00Administration; Management
    • G06Q10/10Office automation; Time management
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/10Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM]
    • G06F21/105Arrangements for software license management or administration, e.g. for managing licenses at corporate level
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q50/00Information and communication technology [ICT] specially adapted for implementation of business processes of specific business sectors, e.g. utilities or tourism
    • G06Q50/10Services
    • G06Q50/18Legal services

Definitions

  • Embodiments of the present invention relate to distributed computing, and more specifically to associating end user license agreements with messages in a distributed computing environment.
  • received messages are added to a queue, and are automatically executed once they reach the head of the queue.
  • Clients and services may include sets of rules that determine how to interpret the messages, how to process the messages, and so on. For example, when a service receives messages from a first client, it may apply rule A to perform a first action, and when the service receives messages from a second client, it may apply rule B to perform a second action. If a received message is in a format that cannot be interpreted by the recipient, then it is not processed.
  • such conventional distributed computing systems do not include a mechanism for establishing a contractual arrangement associated with the messages before those messages are processed.
  • FIG. 1A illustrates a data flow diagram showing a message flowing through a distributed computing system, in accordance with one embodiment of the present invention
  • FIG. 1B illustrates a data flow diagram showing a message flowing through a distributed computing system, in accordance with another embodiment of the present invention
  • FIG. 2 illustrates an exemplary distributed computing system, in which embodiments of the present invention may operate
  • FIG. 3 illustrates a flow diagram of one embodiment for a method of processing a message associated with an end user license agreement
  • FIG. 4 illustrates a flow diagram of another embodiment for a method of processing a message associated with an end user license agreement
  • FIG. 5A illustrates a flow diagram of yet another embodiment for a method of processing a message associated with an end user license agreement
  • FIG. 5B illustrates a flow diagram of still yet another embodiment for a method of processing a message associated with an end user license agreement
  • FIG. 6 illustrates a flow diagram of one embodiment for a method of associating an end user license agreement with a message
  • FIG. 7 illustrates a flow diagram of another embodiment for a method of associating an end user license agreement with a message
  • FIG. 8 illustrates a block diagram of an exemplary computer system, in accordance with one embodiment of the present invention.
  • a message that includes an end user license agreement is received at a client from a service in a distributed computing system.
  • the client determines whether to accept the end user license agreement.
  • the end user license agreement is compared to a list of approved end user license agreements. If the end user license agreement matches an approved end user license agreement on the list, the end user license agreement is accepted without user input. If the end user license agreement does not match an approved end user license agreement on the list, the end user license agreement is presented to a user for approval.
  • the message is processed if the end user license agreement is accepted.
  • an accept response message is sent to a service from which the message was received upon acceptance of the end user license agreement. A second message may then be received from the service.
  • the present invention also relates to an apparatus for performing the operations herein.
  • This apparatus may be specially constructed for the required purposes, or it may comprise a general purpose computer selectively activated or reconfigured by a computer program stored in the computer.
  • a computer program may be stored in a computer readable storage medium, such as, but not limited to, any type of disk including floppy disks, optical disks, CD-ROMs, and magnetic-optical disks, read-only memories (ROMs), random access memories (RAMs), EPROMs, EEPROMs, magnetic or optical cards, or any type of media suitable for storing electronic instructions.
  • a machine-readable medium includes any mechanism for storing or transmitting information in a form readable by a machine (e.g., a computer).
  • a machine-readable medium includes a machine readable storage medium (e.g., read only memory (“ROM”), random access memory (“RAM”), magnetic disk storage media, optical storage media, flash memory devices, etc.), a machine readable transmission medium (electrical, optical, acoustical or other form of propagated signals (e.g., carrier waves, infrared signals, digital signals, etc.)), etc.
  • FIG. 1A illustrates a data flow diagram 100 showing a message flowing through a distributed computing system, in accordance with one embodiment of the present invention.
  • the distributed computing system is implemented as a database management system.
  • the distributed computing system is implemented as a service oriented architecture (SOA) and/or as an enterprise service bus (ESB).
  • SOA service oriented architecture
  • ESD enterprise service bus
  • FIG. 2 An exemplary distributed computing system is illustrated in FIG. 2 below.
  • a service 105 generates a message 115 and transmits it to a client 110 through the distributed computing system.
  • Service 105 may be a discretely defined set of contiguous and autonomous functionality (e.g., business functionality, technical functionality, etc.).
  • Service 105 may be resident on personal computers (PC), servers, routers, etc.
  • Service 105 may represent a process, activity or other resource that can be accessed and used by other services or clients within the distributed computing system.
  • Service 105 may be independent of other services (not shown), and may be accessed without knowledge of its underlying platform implementation.
  • the message 115 may include data that may convey information to, or initiate an event on, client 110 .
  • the message 115 may be generated for any of a myriad of purposes. For example, the message 115 may be generated to report a purchase of a good, to request contact information, to report a result of a remote process, initiate a remote process, etc.
  • message 115 includes a message header, a message context, and a message body.
  • the message header may include a unique message identifier and routing information (e.g., recipient, sender, message priority, etc.).
  • the message header may be used to identify the message 115 , and to route the message 115 to end points (recipients) intended by service 105 , or to other end points determined by the distributed computing system.
  • the message 115 may be directed to a specific endpoint (e.g., client 110 ). Alternatively, the message 115 may be posted to an intermediate location, which one or more endpoints may communicate with to receive the message 115 .
  • the message context may include properties that support compatibility between service 105 and client 110 .
  • the message context may provide, for example, custom fields or filters, transactional information (e.g., to identify a distributed transaction or session associated with the message), security information (e.g., authorization information, authentication information, etc.), and so on.
  • the message body may include data to which a client 110 may respond (e.g., by initiating an event).
  • the content and configuration (layout) of the message body may determine a message type. Examples of message types include text messages, map messages, bytes messages, stream messages and object messages. Other message types are also possible.
  • the message body is formatted using an extensible markup language (XML). Use of XML allows flexible information formats to be implemented. Other flexible information formats, such as standard generalized markup language (SGML) may also be used for the message body.
  • XML extensible markup language
  • the message 115 includes an end user license agreement (EULA) 120 .
  • EULA 120 is a software license agreement that dictates contract terms that the client 110 must accept before utilizing the message 115 .
  • the EULA 120 gives the client 110 an option of accepting or rejecting the license agreement. If the EULA 120 is rejected, the message cannot be processed. If the EULA 120 is accepted, the message 115 can be processed.
  • Client 110 may be, for example, a personal computer (PC), palm-sized computing devices, personal digital assistants (PDA), etc. Client 110 may also be an application run on a PC, server, database, etc. In a service oriented environment (SOA), client 110 includes an application that accesses services (e.g., service 105 ). Client 110 may be a fat client (client that performs local processing and data storage), a thin client (client that performs minimal or no local processing and minimal to no data storage), or a hybrid client (client that performs local processing but little to no data storage).
  • PC personal computer
  • PDA personal digital assistants
  • Client 110 may also be an application run on a PC, server, database, etc.
  • client 110 includes an application that accesses services (e.g., service 105 ).
  • Client 110 may be a fat client (client that performs local processing and data storage), a thin client (client that performs minimal or no local processing and minimal to no data storage), or a hybrid client (client that performs local processing but
  • client 110 includes a rules engine 125 , an end user license agreement (EULA) acceptance rule 130 , and an approved EULA list 140 .
  • the rules engine 125 is a logic component that processes rules (e.g., EULA acceptance rule 130 ) to produce outcomes.
  • the rules engine 125 may match facts, data and rules, and infer conclusions which may result in actions or events of, for example, the client 110 .
  • the rules engine 125 matches the facts, data and rules using a Rete Algorithm.
  • the rules engine 125 may use a Linear Algorithm, Treat Algorithm, Leaps Algorithm, etc. Hybrid algorithms that use combinations of, for example, the Leaps Algorithm and the Rete Algorithm, may also be used.
  • the rules engine 125 Upon client 110 receiving message 115 , the rules engine 125 processes the EULA acceptance rule 130 . In one embodiment, message 115 notifies rules engine 125 that the EULA acceptance rule 130 should be processed. Alternatively, rules engine 125 may determine that the EULA acceptance rule 130 should be processed upon detecting a EULA attached to message 115 .
  • EULA acceptance rule 130 may include conditional elements (e.g., and, or, not, exists, etc.), constraints (e.g., equal to, not equal to, greater than, contains, etc.) and consequences or actions (e.g., decrypt message, process next rule, etc.).
  • the EULA acceptance rule 130 provides instructions on how and whether to process message 115 based on one or more of the EULA 120 , user input, and approved EULA list 140 .
  • a determination on how and whether to process message 115 may also depend on a message body, message header, and/or message context of the message 115 . Other facts and data may also be used in making the determination.
  • the approved EULA list 140 is a list of end user license agreements that have been previously approved for client 110 .
  • approved EULA list 140 includes EULAs that have been approved by a legal department of a business (or other legal entity) that manages or owns client 110 .
  • the approved EULA list 140 may include EULAs that have previously been accepted by a user or administrator of client 110 instead of, or in addition to, EULAs that have been approved by a legal department.
  • EULAs are added to the approved EULA list 140 after they have been accepted a specified number of times (e.g., after a specific EULA is accepted by a user 5 times, 10 times, etc.).
  • the EULA acceptance rule 130 compares the EULA 120 to the approved EULA list 140 . If the EULA 120 matches an entry on the approved EULA list 140 , the rules engine 125 may automatically add the message 115 to a process queue. The message 115 is then processed by client 110 . If the EULA does not match an entry in the approved EULA list 140 , a user may be prompted to accept the EULA 120 . The user may be prompted via a graphical user interface (not shown), and may accept or decline the EULA 120 via an input device (not shown).
  • FIG. 1B illustrates a data flow diagram 150 showing a message flowing through a distributed computing system, in accordance with another embodiment of the present invention.
  • An exemplary distributed computing system is illustrated in FIG. 2 below.
  • a service 107 generates a first message 118 and transmits it to a client 112 through the distributed computing system.
  • the service 107 includes an attachment module 170 , a rules store 175 , a EULA store 180 , a key store 185 and an encrypter 190 .
  • encrypter 190 encrypts the first message 118 such that it can only be decrypted by clients or services that possess an encryption key that was used to perform the encryption.
  • the encrypter 190 may encrypt the first message using conventional encryption algorithms, such as, for example, data encryption standard (DES) or advanced encryption standard (AES).
  • DES data encryption standard
  • AES advanced encryption standard
  • attachment module 170 associates EULA acceptance rule 130 and EULA 120 with message 118 before sending message 118 to client 112 .
  • attachment module 170 may only associate EULA 120 with the message 118 .
  • Attachment module 170 associates rules (e.g., EULA acceptance rule 130 ), EULAs (e.g., EULA 120 ) and/or encryption keys (e.g., key 165 ) with messages (e.g., first message 118 and second message 160 ).
  • rules e.g., EULA acceptance rule 130
  • EULAs e.g., EULA 120
  • encryption keys e.g., key 165
  • attachment module 170 may analyze the message (e.g., to determine a client or service to which the message is directed, to determine a message type and/or message context, etc.), and may examine available rules, EULAs and encryption keys.
  • associating EULA acceptance rule 130 and EULA 120 with first message 118 includes attaching them to the first message 118 .
  • associating the EULA acceptance rule 130 and/or EULA 120 with first message 118 may include placing one or more of the rule or the EULA in the body of first message 118 .
  • rules are stored in rules store 175 .
  • EULAs are stored in EULA store 180 and encryption keys are stored in key store 185 .
  • Each of the rules store 175 , EULA store 180 and key store 185 may include a repository or database in which rules, EULAs or keys (as appropriate) may be managed, organized, searched, etc.
  • Rules store 175 , EULA store 180 and key store 185 may include storage devices such as RAM, hard disk drives, optical drives, etc.
  • Rules store 175 , EULA store 180 and key store 185 may include a single storage device, or multiple networked storage devices at the same or different locations.
  • rules store 175 , EULA store 180 and key store 185 are located at service 107 .
  • one or more of rules store 175 , EULA store 180 and key store 185 may be external to service 107 .
  • the first message 118 includes an end user license agreement (EULA) 120 and a EULA acceptance rule 130 , which may be attached to, or included in a message body of, the first message 118 .
  • EULA end user license agreement
  • EULA acceptance rule 130 which may be attached to, or included in a message body of, the first message 118 .
  • a rules engine 125 Upon client 112 receiving first message 118 , a rules engine 125 processes the EULA acceptance rule 130 included in first message 118 . Alternatively, rules engine 125 may process a EULA acceptance rule stored at client 112 . By processing the EULA acceptance rule 130 , rules engine 125 determines whether to accept or reject EULA 120 (e.g., based on an approved EULA list 140 , user input, etc.). If the EULA 120 is accepted, client 112 generates an accept response message 155 and transmits it to service 107 .
  • service 107 Upon receiving the accept response message 155 , service 107 generates a second message 160 , and transmits it to client 112 .
  • the second message 160 includes data that permits first message 118 to be processed.
  • second message 160 may include necessary instructions that, when added to instructions included in first message 118 , permit a transaction to be executed.
  • second message may include an encryption key (e.g., key 165 ) that can be used to decrypt the first message 118 to permit first message 118 to be processed.
  • attachment module 170 associates an encryption key (e.g., key 165 ) with the second message 160 , as illustrated.
  • the first message 118 is a preliminary message that does not include instructions to be processed other than the EULA 120 and/or the EULA acceptance rule 130 .
  • the second message 160 includes instructions to execute the transaction for which a legal contract was established in the first message 118 .
  • client 112 uses encryption key 165 to decrypt first message 118 upon receiving the second message 160 .
  • First message 118 is then processed.
  • second message 160 is processed upon receipt of the second message 160 .
  • both first message 118 and second message 160 may be processed upon receiving second message 160 .
  • First message 118 and second message 160 may be combined and processed together, or may be processed separately.
  • FIGS. 1A and 1B are described such that a service generates a message, attaches a EULA to the message, etc., and a client receives the message, determines whether to accept the EULA, etc.
  • the roles of the client and the service may be reversed.
  • the client may generate a message, attach a EULA to the message, and send it to the service.
  • the service may receive the message, determine whether to accept the EULA, and process the message.
  • FIG. 2 illustrates an exemplary distributed computing system 200 , in which embodiments of the present invention may operate.
  • the distributed computing system 200 includes a service oriented architecture (SOA).
  • SOA service oriented architecture
  • a service oriented architecture (SOA) is an information system architecture that organizes and uses distributed capabilities (services) for one or more applications.
  • SOA provides a uniform means to offer, discover, interact with and use capabilities (services) distributed over a network. Through the SOA, applications may be designed that combine loosely coupled and interoperable services.
  • the distributed computing system 200 may include clients (e.g., first client 205 and additional clients 225 ) and services (e.g., first service 210 , additional services 230 and core ESB services 215 ), connected via a network 235 .
  • clients e.g., first client 205 and additional clients 225
  • services e.g., first service 210 , additional services 230 and core ESB services 215
  • Each of the clients 205 and 225 and services 210 , 215 , 230 may be both message producers and message consumers, as described below.
  • each of the clients 205 , 225 and services 210 , 215 , 230 may associate EULAs with messages. Thereby, contractual relationships may be formed with some or all messages generated by message producers and processed by message consumers.
  • the network 235 may be a public network (e.g., Internet), a private network (e.g., Ethernet or a local area Network (LAN)), or a combination thereof.
  • the network 235 includes an enterprise service bus (ESB).
  • An ESB is an event-driven and standards-based messaging engine that provides services for more complex architectures.
  • the ESB provides an infrastructure that links together services 210 , 215 , 230 and clients 205 and 225 to enable distributed applications and processes.
  • the ESB may be implemented to facilitate an SOA.
  • the ESB is a single bus that logically interconnects all available services and clients.
  • the ESB may include multiple busses, each of which may logically interconnect different services and/or clients.
  • the first client 205 is a message producer.
  • additional clients 225 , first service 210 , additional services 230 or core ESB services 215 may be message producers.
  • a message producer is a client or service that generates a message. Messages include data that may convey information to, or initiate an event on, a message consumer (e.g., a service or client).
  • a message may be generated for any of a myriad of purposes. For example, the message may be generated to report a purchase of a good, to request contact information, to begin a remote process (e.g., initiate a service), etc.
  • First client 205 includes an attachment module 255 and an end user license agreement 260 .
  • attachment module 255 associates EULA 260 with some or all messages generated by first client 205 .
  • the first service 210 is a message consumer.
  • first client 205 , additional clients 225 , core ESB services 215 or additional services 230 may be message consumers.
  • a message consumer receives a message generated by a message producer, and sent to an address (e.g., service address or client address) of the message consumer. Based on the content of the message, the message consumer may store information contained in the message, generate a response message to send to a service or client, undergo a state change, and/or initiate some other event.
  • a state change initiated by a message may be dependent on contents of the message (e.g., the message body, message context, etc.), rules governing responses to the message, etc.
  • message consumers must accept EULAs associated with received messages before the messages can be processed by the message consumer.
  • First service 210 includes a rules engine 265 .
  • rules engine processes one or more rules (e.g., a EULA acceptance rule) to determine whether to accept the EULA. If the EULA is accepted, first service processes the received message. If the EULA is not accepted, the received message associated with the EULA is not processed.
  • the distributed computing system 200 includes an ESB that has a collection of core ESB services 215 .
  • the core ESB services 215 act on messages that flow through the ESB. Messages can also be directed towards any of the core ESB services 215 in the same manner as described above with reference to the first service 210 and additional services 230 .
  • Any of the core ESB services 215 may include one or more general purpose computing devices (e.g., personal computer or server) and/or special purpose computing devices configured to act on messages that flow between message producers (e.g., clients or services) and message consumers (e.g., clients or services) within the ESB.
  • the core ESB services 215 may include one or more modules 250 , each of which may be a service of the ESB.
  • modules 250 include modules that provide services for splitting a message into multiple messages, routing messages, combining multiple messages into a single message, transforming messages from a first format to a second format, applying rules to a message, storing copies of messages, etc.
  • Each module 250 may provide a service to clients 205 and 225 and/or services 210 and 230 of the distributed computing system 200 .
  • FIG. 3 illustrates a flow diagram of one embodiment for a method 300 of processing a message associated with an end user license agreement (EULA).
  • the method may be performed by processing logic that may comprise hardware (e.g., circuitry, dedicated logic, programmable logic, microcode, etc.), software (such as instructions run on a processing device), or a combination thereof.
  • processing logic may comprise hardware (e.g., circuitry, dedicated logic, programmable logic, microcode, etc.), software (such as instructions run on a processing device), or a combination thereof.
  • method 300 is performed by client 110 of FIG. 1A or client 112 of FIG. 1B .
  • method 300 is performed by a service or client of distributed computing system 200 of FIG. 2 .
  • method 300 includes processing logic receiving a message that includes a EULA (block 305 ).
  • the message may be received by a client or service of a distributed computing system.
  • processing logic determines whether to accept the EULA. Such a determination may be made by processing one or more rules by a rules engine. In one embodiment, the determination of whether to accept the EULA is made automatically by comparing the EULA to a approved EULA list. In another embodiment, a user is prompted to choose whether to accept the EULA. If the EULA is accepted, the method proceeds to block 315 , and the message is processed. If the EULA is not accepted, the method ends.
  • FIG. 4 illustrates a flow diagram of another embodiment for a method 400 of processing a message associated with an end user license agreement (EULA).
  • the method may be performed by processing logic that may comprise hardware (e.g., circuitry, dedicated logic, programmable logic, microcode, etc.), software (such as instructions run on a processing device), or a combination thereof.
  • processing logic may comprise hardware (e.g., circuitry, dedicated logic, programmable logic, microcode, etc.), software (such as instructions run on a processing device), or a combination thereof.
  • method 400 is performed by client 110 of FIG. 1A or client 112 of FIG. 1B .
  • method 400 is performed by a service or client of distributed computing system 200 of FIG. 2 .
  • method 400 includes processing logic receiving a message that includes a EULA (block 405 ).
  • the message may be received by a client or service of a distributed computing system.
  • processing logic compares the EULA to a list of approved EULAs.
  • the list may include entries that represent EULAs that have been approved by a legal department and/or EULAs that have previously been accepted by a user.
  • the method proceeds to block 425 . If the received EULA does not match any entries in the list of approved EULAs, the method proceeds to block 420 .
  • processing logic automatically accepts the EULA. The method then proceeds to block 435 .
  • processing logic presents the EULA to a user.
  • the EULA may be presented to the user via a textual interface, graphical interface, etc.
  • processing logic determines whether the EULA has been accepted by the user. The user may accept or reject the EULA, for example, by using an input device to click on an accept or decline button presented in the user interface. If the user accepts the EULA, the method proceeds to block 435 . If the user rejects the EULA, the method ends.
  • FIG. 5A illustrates a flow diagram of yet another embodiment for a method 500 of processing a message associated with an end user license agreement (EULA).
  • the method may be performed by processing logic that may comprise hardware (e.g., circuitry, dedicated logic, programmable logic, microcode, etc.), software (such as instructions run on a processing device), or a combination thereof.
  • processing logic may comprise hardware (e.g., circuitry, dedicated logic, programmable logic, microcode, etc.), software (such as instructions run on a processing device), or a combination thereof.
  • method 500 is performed by client 110 of FIG. 1A or client 112 of FIG. 1B .
  • method 500 is performed by a service or client of distributed computing system 200 of FIG. 2 .
  • method 500 includes processing logic receiving a message that includes a EULA (block 505 ).
  • the message may be received by a client or service of a distributed computing system.
  • processing logic determines whether to accept the EULA. Such a determination may be made by processing one or more rules by a rules engine. If the EULA is not accepted, the method ends. If the EULA is accepted, the method proceeds to block 515 .
  • processing logic sends an accept response message to a service or client that transmitted the first message.
  • the accept response message notifies the service or client that sent the first message that the EULA associated with the first message has been accepted.
  • processing logic receives a second message from the service or client that sent the first message.
  • the second message includes instructions for a transaction identified in the first message.
  • processing logic determines whether the first message includes instructions for the transaction identified in the first message.
  • the first message may include instructions that, when added to instructions included in the second message, enable a transaction identified in the first message to be processed.
  • the first message may not include any instructions for executing the transaction, in which the second message may include all such instructions. If the first message includes instructions for processing the transaction, the method proceeds to block 530 . If the first message does not include instructions for processing the transaction, the method proceeds to block 535 .
  • both the first message and the second message are processed.
  • the first message and second message are processed together.
  • the first message and second message are combined into a single message by processing logic, after which the combined message is processed.
  • the first message and second message may be processed separately.
  • the second message is processed. The method then ends.
  • FIG. 5B illustrates a flow diagram of still yet another embodiment for a method 550 of processing a message associated with an end user license agreement (EULA).
  • the method may be performed by processing logic that may comprise hardware (e.g., circuitry, dedicated logic, programmable logic, microcode, etc.), software (such as instructions run on a processing device), or a combination thereof.
  • processing logic may comprise hardware (e.g., circuitry, dedicated logic, programmable logic, microcode, etc.), software (such as instructions run on a processing device), or a combination thereof.
  • method 550 is performed by client 110 of FIG. 1A or client 112 of FIG. 1B .
  • method 550 is performed by a service or client of distributed computing system 200 of FIG. 2 .
  • method 550 includes processing logic receiving an encrypted message that includes a EULA (block 555 ).
  • processing logic determines whether to accept the EULA. If the EULA is not accepted, the method ends. If the EULA is accepted, the method proceeds to block 565 .
  • processing logic sends an accept response message to a service (or client) that transmitted the first message.
  • the accept response message notifies the service or client that sent the first message that the EULA associated with the first message has been accepted.
  • processing logic receives a second message that includes an encryption key that was used to encrypt the first message.
  • processing logic uses the encryption key to decrypt the first message.
  • the first message is processed. The method then ends.
  • FIG. 6 illustrates a flow diagram of one embodiment for a method 600 of associating an end user license agreement (EULA) with a message.
  • the method may be performed by processing logic that may comprise hardware (e.g., circuitry, dedicated logic, programmable logic, microcode, etc.), software (such as instructions run on a processing device), or a combination thereof.
  • method 600 is performed by service 110 of FIG. 1A or client 112 of FIG. 1B .
  • method 600 is performed by a service or client of distributed computing system 200 of FIG. 2 .
  • method 600 includes generating a message (block 605 ).
  • processing logic associates a EULA to the message.
  • the EULA may be a EULA that has been generated for a specific client or service to which the message will be sent.
  • the EULA may be a generic EULA that can be used for multiple different services and/or clients.
  • Associating the EULA with the message may include, for example, attaching the EULA to the message, or inserting the EULA into a body of the message.
  • the message is transmitted to a client or service. The method then ends.
  • FIG. 7 illustrates a flow diagram of another embodiment for a method 700 of associating an end user license agreement (EULA) with a message.
  • the method may be performed by processing logic that may comprise hardware (e.g., circuitry, dedicated logic, programmable logic, microcode, etc.), software (such as instructions run on a processing device), or a combination thereof.
  • method 700 is performed by service 110 of FIG. 1A or client 112 of FIG. 1B .
  • method 700 is performed by a service or client of distributed computing system 200 of FIG. 2 .
  • method 700 includes generating a first message (block 705 ).
  • processing logic encrypts the first message using an encryption key.
  • processing logic associates a EULA with the first message.
  • processing logic associates a EULA acceptance rule with the first message.
  • Associating the EULA acceptance rule and the EULA with the first message may include, for example, attaching the EULA and/or the EULA acceptance rule to the first message, or inserting one or more of the EULA and the EULA acceptance rule into a body of the first message.
  • the first message is transmitted to a client or service.
  • an accept response message is received from the client or service.
  • the accept response message indicates that the EULA was accepted.
  • a reject response message may be received, and the method may end.
  • a second message is generated.
  • the encryption key that was used to encrypt the first message is attached to the second message.
  • the second message is transmitted to the client or service. The method then ends.
  • FIG. 8 illustrates a diagrammatic representation of a machine in the exemplary form of a computer system 800 within which a set of instructions, for causing the machine to perform any one or more of the methodologies discussed herein, may be executed.
  • the machine may be connected (e.g., networked) to other machines in a LAN, an intranet, an extranet, or the Internet.
  • the machine may operate in the capacity of a server or a client machine in client-server network environment, or as a peer machine in a peer-to-peer (or distributed) network environment.
  • the machine may be a personal computer (PC), a tablet PC, a set-top box (STB), a Personal Digital Assistant (PDA), a cellular telephone, a web appliance, a server, a network router, switch or bridge, or any machine capable of executing a set of instructions (sequential or otherwise) that specify actions to be taken by that machine.
  • PC personal computer
  • PDA Personal Digital Assistant
  • STB set-top box
  • WPA Personal Digital Assistant
  • a cellular telephone a web appliance
  • server a server
  • network router switch or bridge
  • the exemplary computer system 800 includes a processing device (processor) 802 , a main memory 804 (e.g., read-only memory (ROM), flash memory, dynamic random access memory (DRAM) such as synchronous DRAM (SDRAM) or Rambus DRAM (RDRAM), etc.), a static memory 806 (e.g., flash memory, static random access memory (SRAM), etc.), and a data storage device 818 , which communicate with each other via a bus 830 .
  • ROM read-only memory
  • DRAM dynamic random access memory
  • SDRAM synchronous DRAM
  • RDRAM Rambus DRAM
  • static memory 806 e.g., flash memory, static random access memory (SRAM), etc.
  • SRAM static random access memory
  • Processor 802 represents one or more general-purpose processing devices such as a microprocessor, central processing unit, or the like. More particularly, the processor 802 may be a complex instruction set computing (CISC) microprocessor, reduced instruction set computing (RISC) microprocessor, very long instruction word (VLIW) microprocessor, or a processor implementing other instruction sets or processors implementing a combination of instruction sets.
  • the processor 802 may also be one or more special-purpose processing devices such as an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), a digital signal processor (DSP), network processor, or the like.
  • the processor 802 is configured to execute the processing logic 826 for performing the operations and steps discussed herein.
  • the computer system 800 may further include a network interface device 808 .
  • the computer system 800 also may include a video display unit 810 (e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)), an alphanumeric input device 812 (e.g., a keyboard), a cursor control device 814 (e.g., a mouse), and a signal generation device 816 (e.g., a speaker).
  • a video display unit 810 e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)
  • an alphanumeric input device 812 e.g., a keyboard
  • a cursor control device 814 e.g., a mouse
  • a signal generation device 816 e.g., a speaker
  • the data storage device 818 may include a machine-accessible storage medium 831 on which is stored one or more sets of instructions (e.g., software 822 ) embodying any one or more of the methodologies or functions described herein.
  • the software 822 may also reside, completely or at least partially, within the main memory 804 and/or within the processor 802 during execution thereof by the computer system 800 , the main memory 804 and the processor 802 also constituting machine-accessible storage media.
  • the software 822 may further be transmitted or received over a network 820 via the network interface device 808 .
  • the machine-accessible storage medium 831 may also be used to store data structure sets that define user identifying states and user preferences that define user profiles. Data structure sets and user profiles may also be stored in other sections of computer system 800 , such as static memory 806 .
  • machine-accessible storage medium 831 is shown in an exemplary embodiment to be a single medium, the term “machine-accessible storage medium” should be taken to include a single medium or multiple media (e.g., a centralized or distributed database, and/or associated caches and servers) that store the one or more sets of instructions.
  • the term “machine-accessible storage medium” shall also be taken to include any medium that is capable of storing, encoding or carrying a set of instructions for execution by the machine and that cause the machine to perform any one or more of the methodologies of the present invention.
  • the term “machine-accessible storage medium” shall accordingly be taken to include, but not be limited to, solid-state memories, optical and magnetic media, and carrier wave signals.

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Theoretical Computer Science (AREA)
  • Tourism & Hospitality (AREA)
  • Human Resources & Organizations (AREA)
  • Strategic Management (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • Marketing (AREA)
  • Economics (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Technology Law (AREA)
  • Software Systems (AREA)
  • General Health & Medical Sciences (AREA)
  • Data Mining & Analysis (AREA)
  • Health & Medical Sciences (AREA)
  • Quality & Reliability (AREA)
  • Primary Health Care (AREA)
  • Operations Research (AREA)
  • Multimedia (AREA)
  • Computer Hardware Design (AREA)
  • Computer Security & Cryptography (AREA)
  • General Engineering & Computer Science (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

A server computing device generates a first message that, when executed by a client computing device, will initiate a transaction between the server computing device and the client computing device. The server computing device attaches an end user license agreement to the first message, wherein the end user license agreement dictates terms to be accepted by the client computing device before the transaction is initiated. The server computing device transmits the first message to the client. Responsive to the client computing device accepting the end user license agreement, the server computing device receives an accept response message from the client computing device and transmits a second message to the client computing device.

Description

    RELATED APPLICATIONS
  • This patent application is a divisional application of U.S. patent application Ser. No. 11/980,856, filed Oct. 30, 2007.
  • TECHNICAL FIELD
  • Embodiments of the present invention relate to distributed computing, and more specifically to associating end user license agreements with messages in a distributed computing environment.
  • BACKGROUND
  • In conventional distributed computing systems, received messages are added to a queue, and are automatically executed once they reach the head of the queue. Clients and services may include sets of rules that determine how to interpret the messages, how to process the messages, and so on. For example, when a service receives messages from a first client, it may apply rule A to perform a first action, and when the service receives messages from a second client, it may apply rule B to perform a second action. If a received message is in a format that cannot be interpreted by the recipient, then it is not processed. However, such conventional distributed computing systems do not include a mechanism for establishing a contractual arrangement associated with the messages before those messages are processed.
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • The present invention is illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings and in which:
  • FIG. 1A illustrates a data flow diagram showing a message flowing through a distributed computing system, in accordance with one embodiment of the present invention;
  • FIG. 1B illustrates a data flow diagram showing a message flowing through a distributed computing system, in accordance with another embodiment of the present invention;
  • FIG. 2 illustrates an exemplary distributed computing system, in which embodiments of the present invention may operate;
  • FIG. 3 illustrates a flow diagram of one embodiment for a method of processing a message associated with an end user license agreement;
  • FIG. 4 illustrates a flow diagram of another embodiment for a method of processing a message associated with an end user license agreement;
  • FIG. 5A illustrates a flow diagram of yet another embodiment for a method of processing a message associated with an end user license agreement;
  • FIG. 5B illustrates a flow diagram of still yet another embodiment for a method of processing a message associated with an end user license agreement;
  • FIG. 6 illustrates a flow diagram of one embodiment for a method of associating an end user license agreement with a message;
  • FIG. 7 illustrates a flow diagram of another embodiment for a method of associating an end user license agreement with a message; and
  • FIG. 8 illustrates a block diagram of an exemplary computer system, in accordance with one embodiment of the present invention.
  • DETAILED DESCRIPTION
  • Described herein is a method and apparatus for associating end user license agreements with messages in a distributed computing system. In one embodiment, a message that includes an end user license agreement is received at a client from a service in a distributed computing system. The client determines whether to accept the end user license agreement. In one embodiment, the end user license agreement is compared to a list of approved end user license agreements. If the end user license agreement matches an approved end user license agreement on the list, the end user license agreement is accepted without user input. If the end user license agreement does not match an approved end user license agreement on the list, the end user license agreement is presented to a user for approval. The message is processed if the end user license agreement is accepted. In one embodiment, an accept response message is sent to a service from which the message was received upon acceptance of the end user license agreement. A second message may then be received from the service.
  • In the following description, numerous details are set forth. It will be apparent, however, to one skilled in the art, that the present invention may be practiced without these specific details. In some instances, well-known structures and devices are shown in block diagram form, rather than in detail, in order to avoid obscuring the present invention.
  • Some portions of the detailed description which follows are presented in terms of algorithms and symbolic representations of operations on data bits within a computer memory. These algorithmic descriptions and representations are the means used by those skilled in the data processing arts to most effectively convey the substance of their work to others skilled in the art. An algorithm is here, and generally, conceived to be a self-consistent sequence of steps leading to a desired result. The steps are those requiring physical manipulations of physical quantities. Usually, though not necessarily, these quantities take the form of electrical or magnetic signals capable of being stored, transferred, combined, compared, and otherwise manipulated. It has proven convenient at times, principally for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, or the like.
  • It should be borne in mind, however, that all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities. Unless specifically stated otherwise as apparent from the following discussion, it is appreciated that throughout the description, discussions utilizing terms such as “processing”, “computing”, “calculating”, “determining”, “presenting” or the like, refer to the actions and processes of a computer system, or similar electronic computing device, that manipulates and transforms data represented as physical (e.g., electronic) quantities within the computer system's registers and memories into other data similarly represented as physical quantities within the computer system memories or registers or other such information storage, transmission or display devices.
  • The present invention also relates to an apparatus for performing the operations herein. This apparatus may be specially constructed for the required purposes, or it may comprise a general purpose computer selectively activated or reconfigured by a computer program stored in the computer. Such a computer program may be stored in a computer readable storage medium, such as, but not limited to, any type of disk including floppy disks, optical disks, CD-ROMs, and magnetic-optical disks, read-only memories (ROMs), random access memories (RAMs), EPROMs, EEPROMs, magnetic or optical cards, or any type of media suitable for storing electronic instructions.
  • The algorithms and displays presented herein are not inherently related to any particular computer or other apparatus. Various general purpose systems may be used with programs in accordance with the teachings herein, or it may prove convenient to construct a more specialized apparatus to perform the required method steps. The required structure for a variety of these systems will appear from the description below. In addition, the present invention is not described with reference to any particular programming language. It will be appreciated that a variety of programming languages may be used to implement the teachings of the invention as described herein.
  • A machine-readable medium includes any mechanism for storing or transmitting information in a form readable by a machine (e.g., a computer). For example, a machine-readable medium includes a machine readable storage medium (e.g., read only memory (“ROM”), random access memory (“RAM”), magnetic disk storage media, optical storage media, flash memory devices, etc.), a machine readable transmission medium (electrical, optical, acoustical or other form of propagated signals (e.g., carrier waves, infrared signals, digital signals, etc.)), etc.
  • FIG. 1A illustrates a data flow diagram 100 showing a message flowing through a distributed computing system, in accordance with one embodiment of the present invention. In one embodiment, the distributed computing system is implemented as a database management system. In other embodiments, the distributed computing system is implemented as a service oriented architecture (SOA) and/or as an enterprise service bus (ESB). An exemplary distributed computing system is illustrated in FIG. 2 below.
  • Returning to FIG. 1A, a service 105 generates a message 115 and transmits it to a client 110 through the distributed computing system. Service 105 may be a discretely defined set of contiguous and autonomous functionality (e.g., business functionality, technical functionality, etc.). Service 105 may be resident on personal computers (PC), servers, routers, etc. Service 105 may represent a process, activity or other resource that can be accessed and used by other services or clients within the distributed computing system. Service 105 may be independent of other services (not shown), and may be accessed without knowledge of its underlying platform implementation.
  • The message 115 may include data that may convey information to, or initiate an event on, client 110. The message 115 may be generated for any of a myriad of purposes. For example, the message 115 may be generated to report a purchase of a good, to request contact information, to report a result of a remote process, initiate a remote process, etc.
  • In one embodiment, message 115 includes a message header, a message context, and a message body. The message header may include a unique message identifier and routing information (e.g., recipient, sender, message priority, etc.). The message header may be used to identify the message 115, and to route the message 115 to end points (recipients) intended by service 105, or to other end points determined by the distributed computing system. The message 115 may be directed to a specific endpoint (e.g., client 110). Alternatively, the message 115 may be posted to an intermediate location, which one or more endpoints may communicate with to receive the message 115.
  • The message context may include properties that support compatibility between service 105 and client 110. The message context may provide, for example, custom fields or filters, transactional information (e.g., to identify a distributed transaction or session associated with the message), security information (e.g., authorization information, authentication information, etc.), and so on.
  • The message body may include data to which a client 110 may respond (e.g., by initiating an event). The content and configuration (layout) of the message body may determine a message type. Examples of message types include text messages, map messages, bytes messages, stream messages and object messages. Other message types are also possible. In one embodiment, the message body is formatted using an extensible markup language (XML). Use of XML allows flexible information formats to be implemented. Other flexible information formats, such as standard generalized markup language (SGML) may also be used for the message body.
  • In one embodiment, the message 115 includes an end user license agreement (EULA) 120. The EULA 120 is a software license agreement that dictates contract terms that the client 110 must accept before utilizing the message 115. The EULA 120 gives the client 110 an option of accepting or rejecting the license agreement. If the EULA 120 is rejected, the message cannot be processed. If the EULA 120 is accepted, the message 115 can be processed.
  • Client 110 may be, for example, a personal computer (PC), palm-sized computing devices, personal digital assistants (PDA), etc. Client 110 may also be an application run on a PC, server, database, etc. In a service oriented environment (SOA), client 110 includes an application that accesses services (e.g., service 105). Client 110 may be a fat client (client that performs local processing and data storage), a thin client (client that performs minimal or no local processing and minimal to no data storage), or a hybrid client (client that performs local processing but little to no data storage).
  • In one embodiment, client 110 includes a rules engine 125, an end user license agreement (EULA) acceptance rule 130, and an approved EULA list 140. The rules engine 125 is a logic component that processes rules (e.g., EULA acceptance rule 130) to produce outcomes. The rules engine 125 may match facts, data and rules, and infer conclusions which may result in actions or events of, for example, the client 110. In one embodiment, the rules engine 125 matches the facts, data and rules using a Rete Algorithm. Alternatively, the rules engine 125 may use a Linear Algorithm, Treat Algorithm, Leaps Algorithm, etc. Hybrid algorithms that use combinations of, for example, the Leaps Algorithm and the Rete Algorithm, may also be used.
  • Upon client 110 receiving message 115, the rules engine 125 processes the EULA acceptance rule 130. In one embodiment, message 115 notifies rules engine 125 that the EULA acceptance rule 130 should be processed. Alternatively, rules engine 125 may determine that the EULA acceptance rule 130 should be processed upon detecting a EULA attached to message 115.
  • EULA acceptance rule 130 may include conditional elements (e.g., and, or, not, exists, etc.), constraints (e.g., equal to, not equal to, greater than, contains, etc.) and consequences or actions (e.g., decrypt message, process next rule, etc.). The EULA acceptance rule 130 provides instructions on how and whether to process message 115 based on one or more of the EULA 120, user input, and approved EULA list 140. A determination on how and whether to process message 115 may also depend on a message body, message header, and/or message context of the message 115. Other facts and data may also be used in making the determination.
  • The approved EULA list 140 is a list of end user license agreements that have been previously approved for client 110. In one embodiment, approved EULA list 140 includes EULAs that have been approved by a legal department of a business (or other legal entity) that manages or owns client 110. Alternatively, the approved EULA list 140 may include EULAs that have previously been accepted by a user or administrator of client 110 instead of, or in addition to, EULAs that have been approved by a legal department. In a further embodiment, EULAs are added to the approved EULA list 140 after they have been accepted a specified number of times (e.g., after a specific EULA is accepted by a user 5 times, 10 times, etc.).
  • In one embodiment, the EULA acceptance rule 130 compares the EULA 120 to the approved EULA list 140. If the EULA 120 matches an entry on the approved EULA list 140, the rules engine 125 may automatically add the message 115 to a process queue. The message 115 is then processed by client 110. If the EULA does not match an entry in the approved EULA list 140, a user may be prompted to accept the EULA 120. The user may be prompted via a graphical user interface (not shown), and may accept or decline the EULA 120 via an input device (not shown).
  • FIG. 1B illustrates a data flow diagram 150 showing a message flowing through a distributed computing system, in accordance with another embodiment of the present invention. An exemplary distributed computing system is illustrated in FIG. 2 below.
  • Returning to FIG. 1B, a service 107 generates a first message 118 and transmits it to a client 112 through the distributed computing system. In one embodiment, the service 107 includes an attachment module 170, a rules store 175, a EULA store 180, a key store 185 and an encrypter 190.
  • In one embodiment, encrypter 190 encrypts the first message 118 such that it can only be decrypted by clients or services that possess an encryption key that was used to perform the encryption. The encrypter 190 may encrypt the first message using conventional encryption algorithms, such as, for example, data encryption standard (DES) or advanced encryption standard (AES). Thereby, service 107 may ensure that message 118 can only be processed if the EULA 120 is accepted.
  • In one embodiment, attachment module 170 associates EULA acceptance rule 130 and EULA 120 with message 118 before sending message 118 to client 112. Alternatively, attachment module 170 may only associate EULA 120 with the message 118. Attachment module 170 associates rules (e.g., EULA acceptance rule 130), EULAs (e.g., EULA 120) and/or encryption keys (e.g., key 165) with messages (e.g., first message 118 and second message 160). To determine which rules, EULAs and/or encryption keys to associate with which messages, attachment module 170 may analyze the message (e.g., to determine a client or service to which the message is directed, to determine a message type and/or message context, etc.), and may examine available rules, EULAs and encryption keys. In one embodiment, associating EULA acceptance rule 130 and EULA 120 with first message 118 includes attaching them to the first message 118. Alternatively, associating the EULA acceptance rule 130 and/or EULA 120 with first message 118 may include placing one or more of the rule or the EULA in the body of first message 118.
  • In one embodiment, rules (e.g., EULA acceptance rule 130) are stored in rules store 175. Likewise, in an embodiment, EULAs are stored in EULA store 180 and encryption keys are stored in key store 185. Each of the rules store 175, EULA store 180 and key store 185 may include a repository or database in which rules, EULAs or keys (as appropriate) may be managed, organized, searched, etc. Rules store 175, EULA store 180 and key store 185 may include storage devices such as RAM, hard disk drives, optical drives, etc. Rules store 175, EULA store 180 and key store 185 may include a single storage device, or multiple networked storage devices at the same or different locations. In one embodiment, rules store 175, EULA store 180 and key store 185 are located at service 107. In another embodiment, one or more of rules store 175, EULA store 180 and key store 185 may be external to service 107.
  • In one embodiment, the first message 118 includes an end user license agreement (EULA) 120 and a EULA acceptance rule 130, which may be attached to, or included in a message body of, the first message 118.
  • Upon client 112 receiving first message 118, a rules engine 125 processes the EULA acceptance rule 130 included in first message 118. Alternatively, rules engine 125 may process a EULA acceptance rule stored at client 112. By processing the EULA acceptance rule 130, rules engine 125 determines whether to accept or reject EULA 120 (e.g., based on an approved EULA list 140, user input, etc.). If the EULA 120 is accepted, client 112 generates an accept response message 155 and transmits it to service 107.
  • Upon receiving the accept response message 155, service 107 generates a second message 160, and transmits it to client 112. In one embodiment, the second message 160 includes data that permits first message 118 to be processed. For example, second message 160 may include necessary instructions that, when added to instructions included in first message 118, permit a transaction to be executed. Alternatively, second message may include an encryption key (e.g., key 165) that can be used to decrypt the first message 118 to permit first message 118 to be processed. In such an example, attachment module 170 associates an encryption key (e.g., key 165) with the second message 160, as illustrated. In another embodiment, the first message 118 is a preliminary message that does not include instructions to be processed other than the EULA 120 and/or the EULA acceptance rule 130. In such an embodiment, the second message 160 includes instructions to execute the transaction for which a legal contract was established in the first message 118.
  • In one embodiment, in which the first message 118 is encrypted, client 112 uses encryption key 165 to decrypt first message 118 upon receiving the second message 160. First message 118 is then processed. In another embodiment, in which the first message 118 is a preliminary message, second message 160 is processed upon receipt of the second message 160. Alternatively, both first message 118 and second message 160 may be processed upon receiving second message 160. First message 118 and second message 160 may be combined and processed together, or may be processed separately.
  • Though the embodiments of the present invention shown in FIGS. 1A and 1B are described such that a service generates a message, attaches a EULA to the message, etc., and a client receives the message, determines whether to accept the EULA, etc., the roles of the client and the service may be reversed. For example, the client may generate a message, attach a EULA to the message, and send it to the service. Likewise, the service may receive the message, determine whether to accept the EULA, and process the message.
  • FIG. 2 illustrates an exemplary distributed computing system 200, in which embodiments of the present invention may operate. In one embodiment, the distributed computing system 200 includes a service oriented architecture (SOA). A service oriented architecture (SOA) is an information system architecture that organizes and uses distributed capabilities (services) for one or more applications. SOA provides a uniform means to offer, discover, interact with and use capabilities (services) distributed over a network. Through the SOA, applications may be designed that combine loosely coupled and interoperable services.
  • The distributed computing system 200 may include clients (e.g., first client 205 and additional clients 225) and services (e.g., first service 210, additional services 230 and core ESB services 215), connected via a network 235. Each of the clients 205 and 225 and services 210, 215, 230 may be both message producers and message consumers, as described below. Moreover, each of the clients 205, 225 and services 210, 215, 230 may associate EULAs with messages. Thereby, contractual relationships may be formed with some or all messages generated by message producers and processed by message consumers.
  • The network 235 may be a public network (e.g., Internet), a private network (e.g., Ethernet or a local area Network (LAN)), or a combination thereof. In one embodiment, the network 235 includes an enterprise service bus (ESB). An ESB is an event-driven and standards-based messaging engine that provides services for more complex architectures. The ESB provides an infrastructure that links together services 210, 215, 230 and clients 205 and 225 to enable distributed applications and processes. The ESB may be implemented to facilitate an SOA. In one embodiment, the ESB is a single bus that logically interconnects all available services and clients. Alternatively, the ESB may include multiple busses, each of which may logically interconnect different services and/or clients.
  • In the illustrated embodiment, the first client 205 is a message producer. Alternatively, additional clients 225, first service 210, additional services 230 or core ESB services 215 may be message producers. A message producer is a client or service that generates a message. Messages include data that may convey information to, or initiate an event on, a message consumer (e.g., a service or client). A message may be generated for any of a myriad of purposes. For example, the message may be generated to report a purchase of a good, to request contact information, to begin a remote process (e.g., initiate a service), etc.
  • First client 205 includes an attachment module 255 and an end user license agreement 260. In one embodiment, attachment module 255 associates EULA 260 with some or all messages generated by first client 205.
  • In the illustrated embodiment, the first service 210 is a message consumer. Alternatively, first client 205, additional clients 225, core ESB services 215 or additional services 230 may be message consumers. A message consumer receives a message generated by a message producer, and sent to an address (e.g., service address or client address) of the message consumer. Based on the content of the message, the message consumer may store information contained in the message, generate a response message to send to a service or client, undergo a state change, and/or initiate some other event. A state change initiated by a message may be dependent on contents of the message (e.g., the message body, message context, etc.), rules governing responses to the message, etc. In one embodiment, message consumers must accept EULAs associated with received messages before the messages can be processed by the message consumer.
  • First service 210 includes a rules engine 265. When a message is received from first client that has a EULA associated with it, rules engine processes one or more rules (e.g., a EULA acceptance rule) to determine whether to accept the EULA. If the EULA is accepted, first service processes the received message. If the EULA is not accepted, the received message associated with the EULA is not processed.
  • In one embodiment, the distributed computing system 200 includes an ESB that has a collection of core ESB services 215. The core ESB services 215 act on messages that flow through the ESB. Messages can also be directed towards any of the core ESB services 215 in the same manner as described above with reference to the first service 210 and additional services 230. Any of the core ESB services 215 may include one or more general purpose computing devices (e.g., personal computer or server) and/or special purpose computing devices configured to act on messages that flow between message producers (e.g., clients or services) and message consumers (e.g., clients or services) within the ESB.
  • The core ESB services 215 may include one or more modules 250, each of which may be a service of the ESB. Examples of modules 250 include modules that provide services for splitting a message into multiple messages, routing messages, combining multiple messages into a single message, transforming messages from a first format to a second format, applying rules to a message, storing copies of messages, etc. Each module 250 may provide a service to clients 205 and 225 and/or services 210 and 230 of the distributed computing system 200.
  • FIG. 3 illustrates a flow diagram of one embodiment for a method 300 of processing a message associated with an end user license agreement (EULA). The method may be performed by processing logic that may comprise hardware (e.g., circuitry, dedicated logic, programmable logic, microcode, etc.), software (such as instructions run on a processing device), or a combination thereof. In one embodiment, method 300 is performed by client 110 of FIG. 1A or client 112 of FIG. 1B. In an alternative embodiment, method 300 is performed by a service or client of distributed computing system 200 of FIG. 2.
  • Referring to FIG. 3, method 300 includes processing logic receiving a message that includes a EULA (block 305). The message may be received by a client or service of a distributed computing system. At block 310, processing logic determines whether to accept the EULA. Such a determination may be made by processing one or more rules by a rules engine. In one embodiment, the determination of whether to accept the EULA is made automatically by comparing the EULA to a approved EULA list. In another embodiment, a user is prompted to choose whether to accept the EULA. If the EULA is accepted, the method proceeds to block 315, and the message is processed. If the EULA is not accepted, the method ends.
  • FIG. 4 illustrates a flow diagram of another embodiment for a method 400 of processing a message associated with an end user license agreement (EULA). The method may be performed by processing logic that may comprise hardware (e.g., circuitry, dedicated logic, programmable logic, microcode, etc.), software (such as instructions run on a processing device), or a combination thereof. In one embodiment, method 400 is performed by client 110 of FIG. 1A or client 112 of FIG. 1B. In an alternative embodiment, method 400 is performed by a service or client of distributed computing system 200 of FIG. 2.
  • Referring to FIG. 4, method 400 includes processing logic receiving a message that includes a EULA (block 405). The message may be received by a client or service of a distributed computing system. At block 410, processing logic compares the EULA to a list of approved EULAs. The list may include entries that represent EULAs that have been approved by a legal department and/or EULAs that have previously been accepted by a user.
  • At block 415, if the received EULA matches an entry in the list of approved EULAs, the method proceeds to block 425. If the received EULA does not match any entries in the list of approved EULAs, the method proceeds to block 420.
  • At block 425, processing logic automatically accepts the EULA. The method then proceeds to block 435.
  • At block 420, processing logic presents the EULA to a user. The EULA may be presented to the user via a textual interface, graphical interface, etc. At block 430, processing logic determines whether the EULA has been accepted by the user. The user may accept or reject the EULA, for example, by using an input device to click on an accept or decline button presented in the user interface. If the user accepts the EULA, the method proceeds to block 435. If the user rejects the EULA, the method ends.
  • At block 435, the message is processed. The method then ends.
  • FIG. 5A illustrates a flow diagram of yet another embodiment for a method 500 of processing a message associated with an end user license agreement (EULA). The method may be performed by processing logic that may comprise hardware (e.g., circuitry, dedicated logic, programmable logic, microcode, etc.), software (such as instructions run on a processing device), or a combination thereof. In one embodiment, method 500 is performed by client 110 of FIG. 1A or client 112 of FIG. 1B. In an alternative embodiment, method 500 is performed by a service or client of distributed computing system 200 of FIG. 2.
  • Referring to FIG. 5A, method 500 includes processing logic receiving a message that includes a EULA (block 505). The message may be received by a client or service of a distributed computing system. At block 510, processing logic determines whether to accept the EULA. Such a determination may be made by processing one or more rules by a rules engine. If the EULA is not accepted, the method ends. If the EULA is accepted, the method proceeds to block 515.
  • At block 515, processing logic sends an accept response message to a service or client that transmitted the first message. The accept response message notifies the service or client that sent the first message that the EULA associated with the first message has been accepted.
  • At block 520, processing logic receives a second message from the service or client that sent the first message. In one embodiment, the second message includes instructions for a transaction identified in the first message.
  • At block 525, processing logic determines whether the first message includes instructions for the transaction identified in the first message. For example, the first message may include instructions that, when added to instructions included in the second message, enable a transaction identified in the first message to be processed. Alternatively, the first message may not include any instructions for executing the transaction, in which the second message may include all such instructions. If the first message includes instructions for processing the transaction, the method proceeds to block 530. If the first message does not include instructions for processing the transaction, the method proceeds to block 535.
  • At block 530, both the first message and the second message are processed. In one embodiment, the first message and second message are processed together. In a further embodiment, the first message and second message are combined into a single message by processing logic, after which the combined message is processed. Alternatively, the first message and second message may be processed separately.
  • At block 535, the second message is processed. The method then ends.
  • FIG. 5B illustrates a flow diagram of still yet another embodiment for a method 550 of processing a message associated with an end user license agreement (EULA). The method may be performed by processing logic that may comprise hardware (e.g., circuitry, dedicated logic, programmable logic, microcode, etc.), software (such as instructions run on a processing device), or a combination thereof. In one embodiment, method 550 is performed by client 110 of FIG. 1A or client 112 of FIG. 1B. In an alternative embodiment, method 550 is performed by a service or client of distributed computing system 200 of FIG. 2.
  • Referring to FIG. 5B, method 550 includes processing logic receiving an encrypted message that includes a EULA (block 555). At block 560, processing logic determines whether to accept the EULA. If the EULA is not accepted, the method ends. If the EULA is accepted, the method proceeds to block 565.
  • At block 565, processing logic sends an accept response message to a service (or client) that transmitted the first message. The accept response message notifies the service or client that sent the first message that the EULA associated with the first message has been accepted.
  • At block 568, processing logic receives a second message that includes an encryption key that was used to encrypt the first message. At block 575, processing logic uses the encryption key to decrypt the first message. At block 580, the first message is processed. The method then ends.
  • FIG. 6 illustrates a flow diagram of one embodiment for a method 600 of associating an end user license agreement (EULA) with a message. The method may be performed by processing logic that may comprise hardware (e.g., circuitry, dedicated logic, programmable logic, microcode, etc.), software (such as instructions run on a processing device), or a combination thereof. In one embodiment, method 600 is performed by service 110 of FIG. 1A or client 112 of FIG. 1B. In an alternative embodiment, method 600 is performed by a service or client of distributed computing system 200 of FIG. 2.
  • Referring to FIG. 6, method 600 includes generating a message (block 605). At block 610, processing logic associates a EULA to the message. The EULA may be a EULA that has been generated for a specific client or service to which the message will be sent. Alternatively, the EULA may be a generic EULA that can be used for multiple different services and/or clients. Associating the EULA with the message may include, for example, attaching the EULA to the message, or inserting the EULA into a body of the message. At block 615, the message is transmitted to a client or service. The method then ends.
  • FIG. 7 illustrates a flow diagram of another embodiment for a method 700 of associating an end user license agreement (EULA) with a message. The method may be performed by processing logic that may comprise hardware (e.g., circuitry, dedicated logic, programmable logic, microcode, etc.), software (such as instructions run on a processing device), or a combination thereof. In one embodiment, method 700 is performed by service 110 of FIG. 1A or client 112 of FIG. 1B. In an alternative embodiment, method 700 is performed by a service or client of distributed computing system 200 of FIG. 2.
  • Referring to FIG. 7, method 700 includes generating a first message (block 705). At block 710, processing logic encrypts the first message using an encryption key. At block 715, processing logic associates a EULA with the first message. At block 720, processing logic associates a EULA acceptance rule with the first message. Associating the EULA acceptance rule and the EULA with the first message may include, for example, attaching the EULA and/or the EULA acceptance rule to the first message, or inserting one or more of the EULA and the EULA acceptance rule into a body of the first message.
  • At block 725 the first message is transmitted to a client or service. At block 730, an accept response message is received from the client or service. The accept response message indicates that the EULA was accepted. In one embodiment, if the EULA is declined, a reject response message may be received, and the method may end.
  • At block 735 a second message is generated. At block 740 the encryption key that was used to encrypt the first message is attached to the second message. At block 745, the second message is transmitted to the client or service. The method then ends.
  • FIG. 8 illustrates a diagrammatic representation of a machine in the exemplary form of a computer system 800 within which a set of instructions, for causing the machine to perform any one or more of the methodologies discussed herein, may be executed. In alternative embodiments, the machine may be connected (e.g., networked) to other machines in a LAN, an intranet, an extranet, or the Internet. The machine may operate in the capacity of a server or a client machine in client-server network environment, or as a peer machine in a peer-to-peer (or distributed) network environment. The machine may be a personal computer (PC), a tablet PC, a set-top box (STB), a Personal Digital Assistant (PDA), a cellular telephone, a web appliance, a server, a network router, switch or bridge, or any machine capable of executing a set of instructions (sequential or otherwise) that specify actions to be taken by that machine. Further, while only a single machine is illustrated, the term “machine” shall also be taken to include any collection of machines that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein.
  • The exemplary computer system 800 includes a processing device (processor) 802, a main memory 804 (e.g., read-only memory (ROM), flash memory, dynamic random access memory (DRAM) such as synchronous DRAM (SDRAM) or Rambus DRAM (RDRAM), etc.), a static memory 806 (e.g., flash memory, static random access memory (SRAM), etc.), and a data storage device 818, which communicate with each other via a bus 830.
  • Processor 802 represents one or more general-purpose processing devices such as a microprocessor, central processing unit, or the like. More particularly, the processor 802 may be a complex instruction set computing (CISC) microprocessor, reduced instruction set computing (RISC) microprocessor, very long instruction word (VLIW) microprocessor, or a processor implementing other instruction sets or processors implementing a combination of instruction sets. The processor 802 may also be one or more special-purpose processing devices such as an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), a digital signal processor (DSP), network processor, or the like. The processor 802 is configured to execute the processing logic 826 for performing the operations and steps discussed herein.
  • The computer system 800 may further include a network interface device 808. The computer system 800 also may include a video display unit 810 (e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)), an alphanumeric input device 812 (e.g., a keyboard), a cursor control device 814 (e.g., a mouse), and a signal generation device 816 (e.g., a speaker).
  • The data storage device 818 may include a machine-accessible storage medium 831 on which is stored one or more sets of instructions (e.g., software 822) embodying any one or more of the methodologies or functions described herein. The software 822 may also reside, completely or at least partially, within the main memory 804 and/or within the processor 802 during execution thereof by the computer system 800, the main memory 804 and the processor 802 also constituting machine-accessible storage media. The software 822 may further be transmitted or received over a network 820 via the network interface device 808.
  • The machine-accessible storage medium 831 may also be used to store data structure sets that define user identifying states and user preferences that define user profiles. Data structure sets and user profiles may also be stored in other sections of computer system 800, such as static memory 806.
  • While the machine-accessible storage medium 831 is shown in an exemplary embodiment to be a single medium, the term “machine-accessible storage medium” should be taken to include a single medium or multiple media (e.g., a centralized or distributed database, and/or associated caches and servers) that store the one or more sets of instructions. The term “machine-accessible storage medium” shall also be taken to include any medium that is capable of storing, encoding or carrying a set of instructions for execution by the machine and that cause the machine to perform any one or more of the methodologies of the present invention. The term “machine-accessible storage medium” shall accordingly be taken to include, but not be limited to, solid-state memories, optical and magnetic media, and carrier wave signals.
  • It is to be understood that the above description is intended to be illustrative, and not restrictive. Many other embodiments will be apparent to those of skill in the art upon reading and understanding the above description. The scope of the invention should, therefore, be determined with reference to the appended claims, along with the full scope of equivalents to which such claims are entitled.

Claims (20)

What is claimed is:
1. A method comprising:
generating, by a server computing device, a first message that, when executed by a client computing device, will initiate a transaction between the server computing device and the client computing device in a distributed computing system comprising the server computing device, the client computing device and an enterprise service bus, wherein the enterprise service bus is an event-driven and standards-based messaging engine that links together the server computing device and the client computing device;
attaching, by the server computing device, an end user license agreement to the first message, wherein the end user license agreement dictates terms to be accepted by the client computing device before the transaction is initiated;
transmitting the first message to the client computing device; and
responsive to the client computing device accepting the end user license agreement, receiving an accept response message from the client computing device and transmitting a second message to the client computing device.
2. The method of claim 1, further comprising:
attaching the end user license agreement acceptance rule to the first message, wherein the end user license agreement acceptance rule, when processed by a rules engine at the client computing device, causes the rules engine to:
detect whether a criterion specified in the end user license agreement acceptance rule is satisfied; and
automatically accept the end user license agreement responsive to detecting that the criterion is satisfied.
3. The method of claim 2, wherein the end user license agreement acceptance rule further determines what actions for the client computing device to take in response to an acceptance of the end user license agreement and determines what actions for the client computing device to take in response to a refusal of the end user license agreement.
4. The method of claim 2, wherein the end user license agreement acceptance rule further comprises a list of approved end user license agreements, and wherein the criterion is satisfied if the end user license agreement is included in the list of approved end user license agreement acceptance rules.
5. The method of claim 1, further comprising:
encrypting the first message using an encryption key, wherein the first message is unreadable by the client computing device unless the client computing device accepts the end user license agreement.
6. The method of claim 5, further comprising:
attaching the encryption key to the second message, wherein the encryption key enables the first message to be decrypted.
7. The method of claim 1, further comprising:
analyzing the first message to determine the end user license agreement to attach to the first message, wherein the end user license agreement is determined based on at least one of the client computing device to which the first message is directed, a message type of the first message or a message context of the first message.
8. A non-transitory computer readable storage medium having instructions that, when executed by a server computing device, cause the server computing device to perform operations comprising:
generating, by the server computing device, a first message that, when executed by a client computing device, will initiate a transaction between the server computing device and the client computing device;
attaching, by the server computing device, an end user license agreement to the first message, wherein the end user license agreement dictates terms to be accepted by the client computing device before the transaction is initiated;
transmitting the first message to the client computing device; and
responsive to the client computing device accepting the end user license agreement, receiving an accept response message from the client computing device and transmitting a second message to the client computing device.
9. The non-transitory computer readable storage medium of claim 8, wherein the client computing device and the server computing devices are components of a distributed computing system comprising the server computing device, the client computing device and an enterprise service bus, wherein the enterprise service bus is an event-driven and standards-based messaging engine that links together the server computing device and the client computing device
10. The non-transitory computer readable storage medium of claim 8, the operations further comprising:
attaching the end user license agreement acceptance rule to the first message, wherein the end user license agreement acceptance rule, when processed by a rules engine at the client computing device, causes the rules engine to:
detect whether a criterion specified in the end user license agreement acceptance rule is satisfied; and
automatically accept the end user license agreement responsive to detecting that the criterion is satisfied.
11. The non-transitory computer readable storage medium of claim 10, wherein the end user license agreement acceptance rule further determines what actions for the client computing device to take in response to an acceptance of the end user license agreement and determines what actions for the client computing device to take in response to a refusal of the end user license agreement.
12. The non-transitory computer readable storage medium of claim 10, wherein the end user license agreement acceptance rule further comprises a list of approved end user license agreements, and wherein the criterion is satisfied if the end user license agreement is included in the list of approved end user license agreement acceptance rules.
13. The non-transitory computer readable storage medium of claim 8, the operations further comprising:
encrypting the first message using an encryption key, wherein the first message is unreadable by the client computing device unless the client computing device accepts the end user license agreement.
14. The non-transitory computer readable storage medium of claim 13, the operations further comprising:
attaching the encryption key to the second message, wherein the encryption key enables the first message to be decrypted.
15. The non-transitory computer readable storage medium of claim 8, the operations further comprising:
analyzing the first message to determine the end user license agreement to attach to the first message, wherein the end user license agreement is determined based on at least one of the client computing device to which the first message is directed, a message type of the first message or a message context of the first message.
16. A computing system comprising:
a server computing device having a memory and a processing device coupled to the memory, the processing device to:
generate a first message that, when executed by a client computing device, will initiate a transaction between the server computing device and the client computing device;
attach an end user license agreement to the first message, wherein the end user license agreement dictates terms to be accepted by the client computing device before the transaction is initiated;
transmit the first message to the client computing device; and
responsive to the client computing device accepting the end user license agreement, receive an accept response message from the client computing device and transmit a second message to the client computing device.
17. The computing system of claim 16, wherein the processing device is further to:
associate an end user license agreement acceptance rule with the first message.
18. The computing system of claim 16, further comprising:
an enterprise service bus, wherein the enterprise service bus is an event-driven and standards-based messaging engine that links together the server computing device and the client computing device; and
the client computing device, wherein the client computing device is to:
receive the first message from the server computing device via the enterprise service bus; and
responsive to accepting the end user license agreement, send the accept response message to the service, receive the second message from the service, and process the first message and the second message.
19. The computing system of claim 18, wherein the client computing device comprises a rules engine, the client computing device further to:
identify an end user license agreement acceptance rule associated with the message;
use the rules engine to process the identified end user license agreement acceptance rule to determine whether to automatically accept the end user license agreement without prompting a user for user input; and
automatically accept the end user license agreement responsive to detecting that a first criterion specified for the end user license agreement acceptance rule is satisfied.
20. The computing system of claim 16, the processing device further to:
encrypt the first message using an encryption key, wherein the first message is unreadable by the client computing device unless the client computing device accepts the end user license agreement.
US13/764,653 2007-10-30 2013-02-11 End user license agreements associated with messages Abandoned US20130152165A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US13/764,653 US20130152165A1 (en) 2007-10-30 2013-02-11 End user license agreements associated with messages

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US11/980,856 US8396806B2 (en) 2007-10-30 2007-10-30 End user license agreements associated with messages
US13/764,653 US20130152165A1 (en) 2007-10-30 2013-02-11 End user license agreements associated with messages

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
US11/980,856 Division US8396806B2 (en) 2007-10-30 2007-10-30 End user license agreements associated with messages

Publications (1)

Publication Number Publication Date
US20130152165A1 true US20130152165A1 (en) 2013-06-13

Family

ID=40584127

Family Applications (2)

Application Number Title Priority Date Filing Date
US11/980,856 Active 2030-08-08 US8396806B2 (en) 2007-10-30 2007-10-30 End user license agreements associated with messages
US13/764,653 Abandoned US20130152165A1 (en) 2007-10-30 2013-02-11 End user license agreements associated with messages

Family Applications Before (1)

Application Number Title Priority Date Filing Date
US11/980,856 Active 2030-08-08 US8396806B2 (en) 2007-10-30 2007-10-30 End user license agreements associated with messages

Country Status (1)

Country Link
US (2) US8396806B2 (en)

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8443378B2 (en) * 2007-05-31 2013-05-14 Red Hat, Inc. Method and apparatus for associating rules with messages and using the rules for message processing
US20090265180A1 (en) * 2008-04-21 2009-10-22 Microsoft Corporation Machine-readable end user license agreement with automated acceptance
CA2680594A1 (en) * 2009-10-15 2009-12-23 Ibm Canada Limited - Ibm Canada Limitee Ensuring acceptability of software license agreements or legal agreements
US8484659B2 (en) * 2010-04-20 2013-07-09 Management Systems Resources, Inc. Distributed processing of binary objects via message queues including a failover safeguard
US9710649B2 (en) 2011-09-12 2017-07-18 International Business Machines Corporation Techniques for presenting and collecting end user license agreement acceptance
US20130173642A1 (en) * 2011-12-30 2013-07-04 Nokia Corporation Method and apparatus for consent document management
US9613191B1 (en) * 2015-11-17 2017-04-04 International Business Machines Corporation Access to an electronic asset using content augmentation
US11528601B1 (en) 2021-06-09 2022-12-13 T-Mobile Usa, Inc. Determining and ameliorating wireless telecommunication network functionalities that are impaired when using end-to-end encryption

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050097055A1 (en) * 2003-09-30 2005-05-05 Takeshi Kanamori Computer-implemented intellectual property technology transfer method and system
US7031943B1 (en) * 2000-05-10 2006-04-18 Cisco Technology, Inc. Digital license agreement
US20070083926A1 (en) * 2005-10-07 2007-04-12 Burkhart Michael J Creating rules for the administration of end-user license agreements
US20070100762A1 (en) * 2005-10-31 2007-05-03 Zhonghai Luo Secure license key method and system

Family Cites Families (52)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB8324442D0 (en) 1983-09-13 1983-10-12 Matburn Holdings Ltd Electrosurgical system
US4739759A (en) 1985-02-26 1988-04-26 Concept, Inc. Microprocessor controlled electrosurgical generator
EP0225973A3 (en) 1985-11-01 1988-06-29 Hewlett-Packard Company Electromagnetic field probe
DE3703218A1 (en) 1987-01-31 1988-08-11 Licentia Gmbh Current limiting for a three-phase invertor which is operated using a servo controller (follow-up controller)
US5159929A (en) 1990-06-14 1992-11-03 Morris G Ronald Insulated rf shield
WO1993003677A2 (en) 1991-08-12 1993-03-04 Karl Storz Gmbh & Co. Surgical high-frequency generator for cutting tissues
US5305760A (en) 1992-02-07 1994-04-26 Interflo Medical Inc. Method for rejecting electrical interference from physiological measurements
US5400267A (en) 1992-12-08 1995-03-21 Hemostatix Corporation Local in-device memory feature for electrically powered medical equipment
US5617857A (en) 1995-06-06 1997-04-08 Image Guided Technologies, Inc. Imaging system having interactive medical instruments and methods
AU710400B2 (en) 1995-06-06 1999-09-16 Sherwood Services Ag Digital waveform generation for electrosurgical generators
US5836943A (en) 1996-08-23 1998-11-17 Team Medical, L.L.C. Electrosurgical generator
US6117126A (en) 1996-08-29 2000-09-12 Bausch & Lomb Surgical, Inc. Surgical module with independent microprocessor-based communication
WO1998014129A1 (en) 1996-09-30 1998-04-09 Minnesota Mining And Manufacturing Company Powered surgical instruments and control unit
US5878431A (en) * 1996-10-04 1999-03-02 Hewlett-Packard Company Method and apparatus for providing topology based enterprise management services
EP0973454B1 (en) 1998-02-10 2007-01-17 Biosense Webster, Inc. Probe assembly for improved catheter calibration
US6162216A (en) 1998-03-02 2000-12-19 Guziak; Robert Andrew Method for biopsy and ablation of tumor cells
US6540695B1 (en) 1998-04-08 2003-04-01 Senorx, Inc. Biopsy anchor device with cutter
GB9911956D0 (en) 1999-05-21 1999-07-21 Gyrus Medical Ltd Electrosurgery system and method
US20030181898A1 (en) 1999-05-28 2003-09-25 Bowers William J. RF filter for an electrosurgical generator
US6306132B1 (en) 1999-06-17 2001-10-23 Vivant Medical Modular biopsy and microwave ablation needle delivery apparatus adapted to in situ assembly and method of use
US6607528B1 (en) 1999-06-22 2003-08-19 Senorx, Inc. Shapeable electrosurgical scalpel
WO2001017452A1 (en) 1999-09-08 2001-03-15 Curon Medical, Inc. System for controlling a family of treatment devices
US6238388B1 (en) 1999-09-10 2001-05-29 Alan G. Ellman Low-voltage electrosurgical apparatus
US6432065B1 (en) 1999-12-17 2002-08-13 Ethicon Endo-Surgery, Inc. Method for using a surgical biopsy system with remote control for selecting and operational mode
US20040181219A1 (en) 2000-02-08 2004-09-16 Gyrus Medical Limited Electrosurgical instrument and an electrosugery system including such an instrument
US7080078B1 (en) 2000-05-09 2006-07-18 Sun Microsystems, Inc. Mechanism and apparatus for URI-addressable repositories of service advertisements and other content in a distributed computing environment
EP1157667A3 (en) 2000-05-25 2003-07-02 Ethicon Endo-Surgery, Inc. Electrosurgical generator with RF leakage reduction
ATE369800T1 (en) 2000-09-24 2007-09-15 Medtronic Inc MOTOR CONTROL SYSTEM FOR A SURGICAL HANDPIECE
US6632183B2 (en) 2001-02-12 2003-10-14 Thermal Technologies, Inc. Perfusion sensitive biopsy extractor
JP2002320325A (en) 2001-04-18 2002-10-31 Toenec Corp Power transmission and distribution equipment
US7702563B2 (en) * 2001-06-11 2010-04-20 Otc Online Partners Integrated electronic exchange of structured contracts with dynamic risk-based transaction permissioning
US7143409B2 (en) * 2001-06-29 2006-11-28 International Business Machines Corporation Automated entitlement verification for delivery of licensed software
US7185342B1 (en) 2001-07-24 2007-02-27 Oracle International Corporation Distributed service aggregation and composition
JP4450622B2 (en) 2001-09-28 2010-04-14 アンジオ ダイナミクス インコーポレイテッド Impedance-controlled tissue peeling device and method
US7159224B2 (en) 2002-04-09 2007-01-02 Sun Microsystems, Inc. Method, system, and articles of manufacture for providing a servlet container based web service endpoint
US7222106B2 (en) * 2002-05-21 2007-05-22 International Business Machines Corporation Mechanisms for handling software license agreements on multi-user system
US7047488B2 (en) * 2002-07-19 2006-05-16 Open Invention Network Registry driven interoperability and exchange of documents
US7200674B2 (en) * 2002-07-19 2007-04-03 Open Invention Network, Llc Electronic commerce community networks and intra/inter community secure routing implementation
US20050005116A1 (en) * 2002-09-18 2005-01-06 Commerce One Operations, Inc. Dynamic interoperability contract for web services
US7444522B1 (en) * 2002-09-18 2008-10-28 Open Invention Network, Llc Dynamic negotiation of security arrangements between web services
US7340508B1 (en) * 2002-09-18 2008-03-04 Open Invention Network, Llc Exposing process flows and choreography controllers as web services
US6960209B2 (en) 2002-10-23 2005-11-01 Medtronic, Inc. Electrosurgical methods and apparatus for making precise incisions in body vessels
US20050119646A1 (en) 2002-11-13 2005-06-02 Artemis Medical, Inc. Devices and methods for controlling movement of an electrosurgical electrode
EP1567083A4 (en) 2002-11-13 2008-08-20 Artemis Medical Inc Devices and methods for controlling initial movement of an electrosurgical electrode
DE10327237A1 (en) 2003-06-17 2005-01-13 Trumpf Medizin Systeme Gmbh + Co. Kg Electrosurgical instrument for an endoscope
US20050033588A1 (en) * 2003-08-04 2005-02-10 Mario Ruiz Information system comprised of synchronized software application moduless with individual databases for implementing and changing business requirements to be automated
JP2005102750A (en) 2003-09-26 2005-04-21 Olympus Corp Electrosurgical power supply apparatus
ATE437611T1 (en) 2003-10-29 2009-08-15 Celon Ag Medical Instruments MEDICAL DEVICE FOR ELECTROTOMY
AU2003294390A1 (en) 2003-11-20 2005-07-14 Sherwood Services Ag Electrosurgical pencil with plurality of controls
US20050289072A1 (en) * 2004-06-29 2005-12-29 Vinay Sabharwal System for automatic, secure and large scale software license management over any computer network
US20070271275A1 (en) * 2006-05-05 2007-11-22 Fassette Anthony M Database management function provider systems
US8533746B2 (en) * 2006-11-01 2013-09-10 Microsoft Corporation Health integration platform API

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7031943B1 (en) * 2000-05-10 2006-04-18 Cisco Technology, Inc. Digital license agreement
US20050097055A1 (en) * 2003-09-30 2005-05-05 Takeshi Kanamori Computer-implemented intellectual property technology transfer method and system
US20070083926A1 (en) * 2005-10-07 2007-04-12 Burkhart Michael J Creating rules for the administration of end-user license agreements
US20070100762A1 (en) * 2005-10-31 2007-05-03 Zhonghai Luo Secure license key method and system

Also Published As

Publication number Publication date
US8396806B2 (en) 2013-03-12
US20090112771A1 (en) 2009-04-30

Similar Documents

Publication Publication Date Title
US20130152165A1 (en) End user license agreements associated with messages
US11050690B2 (en) Method for providing recording and verification service for data received and transmitted by messenger service, and server using method
US8863155B2 (en) Associating rules with messages and using the rules for message processing
US8788819B2 (en) System and method for a cloud-based electronic communication vault
KR101354898B1 (en) Electronic commerce transactions over a peer-to-peer communications channel
US9002018B2 (en) Encryption key exchange system and method
JP2019506642A (en) Device identifier dependent operation processing for packet-based data communication
US20230095123A1 (en) Systems and Methods for Digitally Signed Contracts with Verifiable Credentials
Javaid et al. Reputation system for IoT data monetization using blockchain
US10715315B1 (en) Secure management of content using a middleware layer between a client and a server
US12033144B2 (en) Systems and methods for improved indexing of non-standardized, custom smart contracts
CN114500093B (en) Safe interaction method and system for message information
Saleem et al. Analysis and design of secure web services
US8826266B2 (en) Updates of message consumers
US7937497B2 (en) Apparatus for selectively copying at least portions of messages in a distributed computing system
US20090113072A1 (en) Hot-swappable services in distributed computing
Costa et al. High-performance blockchain system for fast certification of manufacturing data
US9378348B2 (en) Adding biometric identification to the server security infrastructure for an enterprise service bus system
US20200220898A1 (en) Providing attributes of a network service
US20080299947A1 (en) Addressable dispatchers in distributed computing
CN113609531B (en) Information interaction method, device, equipment, medium and product based on block chain
US8868781B2 (en) Service forwarding addresses in distributed computing
US8752065B2 (en) Rules engine for a persistent message store
US20100175121A1 (en) Adding biometric identification to the client security infrastructure for an enterprise service bus system
US20080301251A1 (en) Debugging in a distributed system

Legal Events

Date Code Title Description
AS Assignment

Owner name: RED HAT, INC., NORTH CAROLINA

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:LITTLE, MARK CAMERON, DR.;REEL/FRAME:030261/0383

Effective date: 20080125

STPP Information on status: patent application and granting procedure in general

Free format text: RESPONSE TO NON-FINAL OFFICE ACTION ENTERED AND FORWARDED TO EXAMINER

STPP Information on status: patent application and granting procedure in general

Free format text: FINAL REJECTION MAILED

STPP Information on status: patent application and granting procedure in general

Free format text: RESPONSE AFTER FINAL ACTION FORWARDED TO EXAMINER

STPP Information on status: patent application and granting procedure in general

Free format text: ADVISORY ACTION MAILED

STPP Information on status: patent application and granting procedure in general

Free format text: DOCKETED NEW CASE - READY FOR EXAMINATION

STPP Information on status: patent application and granting procedure in general

Free format text: NON FINAL ACTION MAILED

STPP Information on status: patent application and granting procedure in general

Free format text: FINAL REJECTION MAILED

STCB Information on status: application discontinuation

Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION