(19) United States
`(12) Patent Application Publication (10) Pub. No.: US 2005/0071276 A1
`Bruchlos et al.
`(43) Pub. Date:
`Mar. 31, 2005
`
`US 20050071276A1
`
`(54) METHOD FOR AUTOMATIC CREATION
`AND CONFIGURATION OF LICENSE
`MODELS AND POLICIES
`
`(75) Inventors: Joachim Bruchlos, CalW (DE);
`Joachim Hagmeier, Stuttgart (DE);
`Dietmar Kuebler, Altdorf (DE); Timo
`Kussmaul, Boeblingen (DE)
`
`Correspondence Address:
`Mark S. Walker
`International Business Machines
`Intellectual Property Law
`11400 Burnet Road
`Austin, TX 78758 (US)
`
`BUSINESS
`(73) Assignee: INTERNATIONAL
`MACHINES
`CORPORATION,
`ARMONK, NY
`
`(21) Appl. No.:
`
`10/876,023
`
`(22) Filed:
`
`Jun. 24, 2004
`
`(30)
`
`Foreign Application Priority Data
`
`Sep. 30, 2003 (EP) ...................................... .. 031036288
`
`Publication Classi?cation
`
`(51) Int. Cl.7 ..................................................... .. H04L 9/00
`(52) US. Cl. .............................................................. .. 705/51
`
`(57)
`
`ABSTRACT
`
`The present invention refers to the ?eld of networked
`computer telecommunication, and in particular to a method
`and system for processing services associated With a con
`tract betWeen a service requester (SC) and a service provider
`(SP) Wherein said services are to be provided via a network,
`Wherein at least one service contract is de?ned betWeen said
`service requester and said service provider. In order to
`improve the processing of Web services, license manage
`ment facilities (75A) are included into the prior art method
`cooperating closely With a Contract Management compo
`nent (74A) and a Service Metering Component (76A).
`Preferably, a plurality of different license types are provided
`for selection to be used, Which may further be combined
`also, in order to match best the needs of a customer.
`
`g
`
`_ .. ,1.
`‘V
`Liens:
`
`.
`
`'
`
`,
`
`i
`
`i
`~
`
`:
`Mata: Ear/ice
`_--_-_-____-___‘_-1
`
`.
`
`_ License Service‘
`1010-|
`
`l
`
`100w 76A/Tm1m
`'
`LICENSE DISPATCHER
`
`Us‘; I“ 1! ‘mg-t 35“
`|
`
`at!“ -
`
`L'keuia
`t
`
`1020
`\
`
`“muse
`'
`'
`1030
`‘ \ '
`
`1040 l
`\
`
`u 114i 11121156
`
`1050
`\
`
`‘vori?raiion
`
`My
`
`i
`
`ll.“
`Rmm'ntinn
`
`|
`
`1 060
`
`LICENSE GENERATOR
`
`l
`
`|
`
`1070\| License li'allhliiin '
`Illesponse
`
`.
`
`C mergers;
`
`ServiceNow's Exhibit No. 1006
`
`001
`
`

`
`Patent Application Publication Mar. 31, 2005 Sheet 1 0f 8
`
`US 2005/0071276 A1
`
`POST /StockQuote HTTP/1.1
`Host: www.stockquoteserver.com
`Content-Type: text/xml; charset="utf-8"
`Content-Length: nnnn
`SOAPAction: "http://examp|e.org/2001IDS/quotes"
`
`<envzEnvelope xmlns:env="http://www.w3.org/2001l06lsoap-envelope" >
`
`<mzGetLastTradePrice
`env:encodingStyle="http://www.w3.org/2001l06lsoap-encoding"
`xmlns:m="http://example.orgl2001/06/quotes">
`<symbol>lBM<lsymbol>
`<lmzGetLastTradePrice>
`</env:Body>
`<lenvzEnvelope>
`
`FIG, 1 PRIOR ART
`
`<Method> <request-UR|> <HTTP-version>
`Header ?eld 1
`
`Header ?eld n
`(blank line)
`Message body
`
`2 PRIORART
`
`<SOAP:Envelope>
`<SOAP:Header>
`Header ?eld 1
`
`Header ?eld n
`</SOAP:Header>
`<SOAP:Body>
`Body ?eld 1
`
`Body ?eld n
`</SOAP:Body>
`</SOAP:Envelope>
`
`3
`PRIOR ART
`
`ServiceNow's Exhibit No. 1006
`
`002
`
`

`
`Patent Application Publication Mar. 31, 2005 Sheet 2 0f 8
`
`US 2005/0071276 A1
`
`<Method> <request-UR|> <HTTP-version>
`Header ?eld 1
`
`Header ?eld n
`(blank line)
`<SOAP:Envelope>
`<SOAP:Header>
`Header ?eld 1
`
`Header ?eld n
`</SOAP:Header>
`<SOAP:Body>
`Body ?eld 1
`
`Body ?eld n
`</SOAP:Body>
`</SOAP:Envelope>
`
`Fl
`
`4 PRIOR ART
`
`ServiceNow's Exhibit No. 1006
`
`003
`
`

`
`Patent Application Publication Mar. 31, 2005 Sheet 3 0f 8
`
`US 2005/0071276 A1
`
`<?xml version="1.0"?>
`<de?nitions name="StockQuote"
`targetNamespace="http:/lexample.com/stockquote.wsdl"
`xm|ns:tns="http://examp|e.com/stockquote.wsdl"
`xmlnszxsd1="httpz/lexample.comlstockquote.xsd"
`xmlns:soap="http://schemas.xmlsoap.org/wsdl/soapl"
`xm|ns="http:l/schemas.xmlsoap.org/wsdl/">
`
`<types>
`<schema targetNamespace="http://example.com/stockquote.xsd"
`xmlns="http://www.w3.org/2000/10/XMLSchema">
`<element name="TradePriceRequest">
`<comp|exType>
`<a||>
`<element name="tickerSymbol" type="string"/>
`<lall>
`<lcomplexType>
`<lelement>
`<element name="TradePrice">
`<complexType>
`<al|>
`<element name="price" type="?oat"l>
`<lal|>
`<lcomplexType>
`<lelement>
`<lschema>
`<ltypes>
`
`<message name="GetLastTradePricelnput">
`<part name="body" element="xsd1:TradePriceRequest"/>
`<lmessage>
`
`F I G _
`
`PRIOR ART
`
`ServiceNow's Exhibit No. 1006
`
`004
`
`

`
`Patent Application Publication Mar. 31, 2005 Sheet 4 0f 8
`
`US 2005/0071276 A1
`
`<message name="GetLastTradePriceOutput">
`<part name="body" element="xsd1:TradePrice"/>
`<lmessage>
`
`<portType name="StockQuotePortType">
`<operation name="GetLastTradePrice">
`<input message="tns:GetLastTradePrice|nput"/>
`<output rpessage="tns:GetLastTradePriceOutput"/>
`<loperation>
`<lportType>
`
`<binding name="StockQuoteSoapBinding" type=
`"tns:StockQuotePortType">
`<soap:binding style="document" transport=
`"httpzllschemas.xmlsoap.org/s0aplhttp"/>
`<operation name="GetLastTradePrice">
`<soapzoperation soapAction=
`"http://example.com/GetLastTradePrice"/>
`<input>
`<soap:body use="|iteral"/>
`</input>
`<output>
`<soap:body use="|iteral"l>
`<loutput>
`<loperation>
`<lbinding>
`
`<service name="StockQuoteService">
`<documentation>My ?rst service<ldocumentation>
`<p0rt name="StockQuotePort" binding="tns:StockQuoteBinding">
`<soapzaddress |ocation=
`"http://www.stockquoteserver.c0m/StockQuote"/>
`<lport>
`<lservice>
`
`<lde?nitions>
`
`PRIOR ART
`
`ServiceNow's Exhibit No. 1006
`
`005
`
`

`
`Patent Application Publication Mar. 31, 2005 Sheet 5 0f 8
`
`US 2005/0071276 A1
`
`Service
`
`Provider
`
`SP
`
`620' 63%
`
`640
`
`650
`Service -— Service
`
`Consumer -—|| Supplier
`SC
`610
`SS
`
`Service
`Provider
`
`SP
`
`810
`
`840
`
`820
`
`830
`
`Service
`Consumer
`SC
`
`Service
`Supplier
`33
`
`FIG. 8
`
`ServiceNow's Exhibit No. 1006
`
`006
`
`

`
`Patent Application Publication Mar. 31, 2005 Sheet 6 0f 8
`
`US 2005/0071276 A1
`
`REMOTE SERVERS 752
`
`SP-Application Server
`
`FIG. 7
`
`ServiceNow's Exhibit No. 1006
`
`007
`
`

`
`Patent Application Publication Mar. 31, 2005 Sheet 7 0f 8
`
`US 2005/0071276 A1
`
`REMOTE SERVERS
`
`SP-Application Server
`
`FIG. 9
`
`ServiceNow's Exhibit No. 1006
`
`008
`
`

`
`ServiceNow's Exhibit No. 1006
`
`009
`
`

`
`US 2005/0071276 A1
`
`Mar. 31, 2005
`
`METHOD FOR AUTOMATIC CREATION AND
`CONFIGURATION OF LICENSE MODELS AND
`POLICIES
`
`BACKGROUND OF THE INVENTION
`
`[0001] 1. Field of the Invention
`
`[0002] The present invention relates to the ?eld of net
`worked computer telecommunication, and in particular to a
`method and system for processing services associated With
`a contract betWeen a service requester (SC) and a service
`provider (SP) Wherein said services are to be provided via a
`network, Wherein at least one service contract is de?ned
`betWeen said service requester and said service provider.
`[0003] 2. Description and Disadvantages of Prior Art
`[0004] Web services de?ne a technique for describing
`softWare components to be accessed, methods for accessing
`these components, and discovery methods that enable the
`identi?cation of relevant service providers. Web services are
`programming language-, programming model-, and system
`softWare neutral.
`
`[0005] In this regard, tWo prior art Web services standards
`are relevant. They are shortly sketched out and commented
`as folloWs in order to introduce into the problems concerned
`in prior art:
`[0006] First, the Simple Object Access Protocol (SOAP)
`provides a means of messaging betWeen a service provider
`and a service requester. SOAP is independent of the under
`lying transport protocol, SOAP payloads can be carried on
`HTTP, FTP, JMS and other protocols.
`[0007] FIG. 1 gives a SOAP example carried by the HTTP
`POST request.
`
`[0008] HTTP messages consist of requests from client to
`server and responses from server to client. Both types of
`message (Request and Response messages) consist of a
`start-line, Zero or more header ?elds (also knoWn as “head
`ers”), an empty line indicating the end of the header ?elds,
`and possibly a message-body.
`
`[0009] The structure of a HTTP request message is
`depicted in FIG. 2: the ?rst line of that message speci?es the
`method to be applied to the resource, the identi?er of the
`resource, and the HTTP protocol version in use. The HTTP
`protocol de?nes multiple request methods like GET, HEAD,
`POST, PUT, DELETE, TRACE, CONNECT, OPTIONS.
`The method indicates the operation to be performed on the
`resource.
`
`[0010] The resource upon Which to apply the request is
`identi?ed by a Request-URI, Which is a Uniform Resource
`Identi?er. Uniform Resource Identi?ers are simply format
`ted strings, Which identify—via name, location, address or
`any other characteristic—a resource. For example: The
`Well-knoWn HTTP URL scheme used to locate netWork
`resources via the HTTP protocol contains resource-URIs.
`The scheme speci?c syntax and semantics for http URLs are
`
`[0012] If the port is empty or not given, port 80 is
`assumed. The semantics are that the identi?ed resource is
`located at the server listening for TCP connections on that
`
`port of that host, and the Request-URI identi?es the
`resource. The syntax and semantics for Request-URI are
`[0013] Request-uri=abs-_path[“?”query-string]
`
`[0014] Where the abs _path is an identi?er of the resource
`and the query string is any kind of information Which can be
`used for processing the request.
`[0015] The header ?elds carry meta-information associ
`ated With the request or response.
`
`[0016] The message-body of an HTTP message is used to
`carry the entity-body associated With the request or
`response. The message body depicted in FIG. 2 contains the
`actual SOAP message, Which has a structure as given in
`FIG. 3: Inside An envelope section a number of header
`?elds 1, .
`.
`. n are de?ned, Which construct the so called
`SOAP header, Which is folloWed by by the actual SOAP
`body, Which comprises a second number of so called “Body
`?elds 1, .
`.
`. n.
`
`[0017] Thus, the overall structure of a SOAP message
`carried over a netWork eg by a transport protocol like
`HTTP is depicted as a conglomeration of FIGS. 1 to 3 in
`FIG. 4.
`
`[0018] FIG. 1 gives a SOAP example carried by the HTTP
`POST command. The HTTP request method is POST, the
`resource-URI is “/StockQuote”, Which is an absolute path
`identifying the resource for Which the request is intended.
`The resource-URI does not contain a query string.
`
`[0019] Beside SOAP, there is in prior art the above
`mentioned second relevant Web Service standard:
`[0020] The Web Services Description Language (WSDL)
`is an XML document for describing Web Services as a set of
`endpoint operations on messages containing either docu
`ment-oriented or Remote Procedure Call (RPC) payloads.
`So called service interfaces are de?ned abstractly in terms of
`message structures and sequences of simple message
`exchanges (or “operations” in WSDL terminology). They
`are then bound to a concrete netWork protocol and data
`encoding format to de?ne an endpoint. Related concrete
`endpoints are bundled to de?ne abstract endpoints (ser
`vices).
`[0021] WSDL supports a service interface de?nition that
`is distinct from the protocol bindings used for service
`invocation. WSDL alloWs for multiple bindings for a single
`service. The service interface de?nition and the access
`binding are also distinct from the implementation of the
`functionality of the service. Service requestors usually gen
`erate client stub code for a Web service from the correspond
`ing WSDL; the WSDL of a service is usually requested from
`the service provider. The client stub code implements the
`necessary logic to create the correct message structure and
`the correct data encoding to address the endpoint. Since
`there is a distinction betWeen de?nition, binding and imple
`mentation of a service, client stub codes created for a certain
`de?nition and binding can usually address various endpoints
`Without requiring code changes, simply by using another
`endpoint address. FIG. 5A and the continuation thereof,
`FIG. 5B is given to disclose an exemplary WSDL document
`With further details to a person skilled in the art.
`
`[0022] An important feature of Web Services is that they
`are stateless, according to a request-response scheme. A
`
`ServiceNow's Exhibit No. 1006
`
`010
`
`

`
`US 2005/0071276 A1
`
`Mar. 31, 2005
`
`stateless server is one, Which treats each request as an
`independent transaction, unrelated to any previous request.
`This simpli?es the server design because it does not need to
`allocate storage to deal With conversations in progress or
`Worry about freeing it if a client dies in mid-transaction. A
`disadvantage is that it may be necessary to include more
`information in each request and this extra-information Will
`need to be interpreted by the server each time.
`
`[0023] Having noW described the constraints in Which
`electronic communication of the above-mentioned kind
`runs, the disadvantages of prior art Will be described neXt
`beloW:
`
`[0024] Commercial usage of Web services is based on a
`contract concluded betWeen the service provider and the
`service requester. Such contract represents an agreement
`about the conditions for using and provisioning Web services
`or Web applications. The contract details may specify the
`conditions for billing the service, ie the price, service levels
`specifying the desired quality of service in a more detailed
`Way, and further information Which is highly critical for both
`the service requestor and the service provider. Basically, in
`prior art business, there are no limitations regarding the
`scope of a contract or the number of contracts: one contract
`may contain multiple services, or one service may be
`contained in multiple contracts, Which are all valid at the
`same time.
`
`[0025] In a typical prior art scenario, either tWo parties, ie,
`the Service Requester or Service Consumer, referred to
`herein as SC, and the Service Provider, referred to as SP,
`communicate, or three parties are comprised of the Web
`service Communication, ie the Service Requester, the Ser
`vice provider Who manages the above contracts and the
`Service Supplier, referred to as SS, Which actually performs
`the service, Which is sometimes hold invisible to the
`requester.
`[0026] The only disclosure of such prior art, Which is thus
`elaborated to address the above-mentioned Web services
`facilities is published in “IBM Web Services Toolkit”
`(“Emerging Technologies Toolkit”), available in the year of
`2002 for a trial period of 60 days based on IBM AlphaWorks
`license agreements.
`
`[0027] A short revieW on a softWare component as it is
`disclosed there, Which is called “Contract Service” and
`comprises the most technical features relevant for the
`present invention is given, as folloWs:
`
`[0028] The Contract Service handles the relationship
`betWeen service providers and service requesters. It provides
`information about the type of contract betWeen a service
`provider and the service hub (deployment contracts, also
`knoWn as provider contracts) and betWeen a service
`requestor and the service hub (usage contracts). Usage
`contracts can be used to subscribe to any combination of
`operations of any service provided through the service hub.
`A usage contract contains information such as hoW calls to
`service operations are to be charged for (by time, by number
`of uses, by amount of use etc.) and hoW much the subscribed
`service operations should cost for that client. For each usage
`contract the Contract Service de?nes the payment method
`and rating model to be used, the effective dates for that
`contract. Contracts may optionally store the digital signa
`tures of both parties (service hub and service provider/
`
`requestor) to the contract. In the Utility Service demo that is
`shipped With the Web Services Toolkit, contracts are added
`to the Contract Service via a Utility Services Portal supplied
`With the demo, and a valid contract must be in place betWeen
`a service hub and a service requestor before the requestor
`can use the service.
`
`[0029] In this prior art contracting system for Web services
`there are a number of disadvantages, introduced as folloWs:
`
`[0030] Web services de?ne a technique for describing
`softWare components the eXecution of Which may have a
`considerable business value for a client, they describe hoW
`such Web services are accessible by the clients and they
`describe discovery methods that enable the identi?cation of
`relevant service providers to a client. Web services are
`mostly programming language-, programming model-, and
`system softWare neutral. Web services as described above
`are of high importance for the neXt future because they form
`a key part of dynamic e-business, and in particular of
`e-business on demand.
`
`[0031] E-business on demand requires besides metering
`and accounting of services sophisticated systems to deal
`With the contractual relationships that have to be in place
`before actual on demand services can be offered to a client.
`
`[0032] There is a remarkable similarity betWeen e-busi
`ness on demand and prior art softWare usage: in both ?elds
`a client is ready to pay some money in order to use a piece
`of softWare the eXecution of Which serves him to get some
`prede?ned business value. As in prior art softWare usage
`different types of licenses are knoWn and are useful to be
`customised to the speci?c needs of a customer it Would be
`strongly desirable also to implement a licensing facility into
`such prior art contract management system, Which performs
`the Web services in favour to a client. The problem is that
`licensing may be considered as a special case, ie a special
`Way of contracting for softWare usage. Disadvantageously
`the prior art contracting systems for performing Web ser
`vices do not offer any licensing until noW. A speci?c
`dif?culty for simply implementing eXisting licensing busi
`ness methods into electronic Web service management is that
`the user Would need a high degree of personalisation in the
`licences, the vendor or provider of a Web service cannot
`implement in program form all desired individual license
`types Which are object of face-to-face negotiations betWeen
`a service provider and a service requestor. Thus, the contract
`and license management basically falls into tWo categories:
`
`a) high level contracting and
`
`[0033]
`[0034] b) loW level contracting.
`
`[0035] High level contracting deals With the above-men
`tioned face-to-face negotiations for agreeing on given con
`tract conditions, While loW level contracting deals With the
`runtime implementations of contract attributes as far as they
`are agreed on by both contracting parties. Personalised
`licenses betWeen a service provider and a service requestor
`of Web services require a great manual afford and are usually
`only set up With customers requiring enough licenses to be
`Worth the afford of negotiation.
`[0036] One of the disadvantageous limitations of the prior
`art contract management is that a one-to-one relationship
`eXists betWeen the consumer and the provider of a service
`offering eXists. This represents a major problem to introduce
`
`ServiceNow's Exhibit No. 1006
`
`011
`
`

`
`US 2005/0071276 A1
`
`Mar. 31, 2005
`
`this system to large scale environments, Where for instance
`enterprises Want to contract services for a number of con
`sumers, for example a large number of employees using
`such services. If prior art contract management systems Was
`enriched With existing softWare licensing knoW-hoW, the
`client could only choose from prede?ned licenses With a
`pre-set number of conditions, under Which he can use the
`softWare or the service. If non of the offered licenses meets
`his requirements he Will have to accept a license, Which does
`not really ?t his needs or, alternatively he cannot use the
`softWare or the service at all.
`
`[0037] In many business situations the negotiations of
`different license policies, as it is basically desirable for a
`client, requires to much interaction in the sales process to be
`Worth the effort for the service supplier. Further, it is also not
`possible to use Well-knoWn and established usage models as
`they are used in prior art softWare licensing, as prior art
`softWare licensing is coupled to offline processes for situa
`tions, in Which the usage of a licensed softWare is done
`offline and independently from the softWare provider or the
`softWare seller.
`
`OBJECTIVES OF THE INVENTION
`[0038] It is thus an objective of the present invention to
`improve prior art methods of performing Web services.
`
`SUMMARY AND ADVANTAGES OF THE
`INVENTION
`[0039] This objective of the invention is achieved by the
`features stated in enclosed independent claims. Further
`advantageous arrangements and embodiments of the inven
`tion are set forth in the respective subclaims. Reference
`should noW be made to the appended claims.
`
`[0040] According to the basic aspect of the present inven
`tion as de?ned in claim 1 a basic approach for improving
`prior art delivering of Web services is disclosed, Wherein a
`service consumer may issue a request for a service With
`using information included in the request, Which comprises
`a kind of user-ID, Which enables a service provider to select
`a valid contract betWeen the service consumer and the
`service provider. Furthermore, at the service provider site, a
`customer-speci?c licensing model is instantiated preferably
`automatically during runtime by using existing license sub
`contracts and respective licensing softWare components in
`cooperation With a service metering component storing all
`necessary usage information on usage of services actually
`provided or provided prior to the current service request, in
`order to ?nd a respective particular license model, Which
`matches best the actual needs of the client, and Which is
`covered by the contractual scope of the negotiated contract
`terms and conditions. Thus, different license policies can be
`folloWed adaptable to the speci?c needs of a service
`requester.
`[0041] A preferred Way to do that is to offer a plurality of
`different license types, Which is able to cover most of the
`clients needs, as experience shoWs. An advantageous col
`lection of different license types comprises the folloWing
`types:
`[0042] a) a consumptive type, in Which only a spe
`ci?c number of requests for the service are alloWed
`optionally, this may be related to a prede?ned time
`period, in Which that number of requests must be
`performed;
`
`[0043] b) a “concurrent” license type, Wherein only a
`speci?c number of simultaneous requests of the
`service are alloWed;
`
`[0044] c) a time-based license type, Wherein service
`requests are alloWed only at speci?c times. This can
`either be periodic, for instance Monday to Friday or
`single type, as for instance January to July 2003;
`
`[0045] d) a name-related license type, in Which only
`prede?ned principles listed in the license policy are
`alloWed to request the service. By that, for example
`a group of 4 persons can use a service;
`
`[0046] e) a “base” type license, Wherein no access
`regulations or usage conditions must be kept, mean
`ing that a service request Will be alWays alloWed
`independently of time, historic consumption and the
`number of concurrent accesses, Which may be pref
`erably granted to a limited number of persons only;
`
`[0047] f) a usage condition license type, in Which a
`license policy speci?es any prede?ned usage condi
`tion, for example the condition that any reselling of
`the provided service is not alloWed of cause other
`conditions may exist, Which depend clearly from the
`particular situation and ?eld of use.
`
`[0048] The above-mentioned different license types are
`referred to be “atomic” license types because each indi
`vidual license type addresses one single and complete sepa
`rate aspect of usage conditions. Further advantageously said
`atomic license types can be combined in order to be able to
`offer a large number of different license models to the
`customer, a preferred feature, Which is not knoWn yet in the
`World for Web services. A combined license type can be
`obtained by associating an individual, predetermined frac
`tion, for instance percentage of each atomic license type to
`the combined one, Which preferably also may be used for
`billing purposes.
`[0049] Further advantageously the de?nition of a license
`or the de?nition of multiple license types according to the
`present invention is part of an electronic document speci
`fying the contract underlying to said licenses. By that the
`advantage results that contract information and license type
`information is stored close to each other, Which increases the
`ease of use When maintaining those data.
`[0050] Further, When the contracting system implement
`ing the different license types according to the present
`invention further includes a metering softWare component
`designed and de?ned for metering the technical details of the
`requested services, in particular those details, Which may be
`used to form part of the billing process postponed to the
`service itself, and When said metering data associated With
`a current contract ID is read and used for a checking step in
`order to make a decision if or if not to alloW a service
`provision, then one and the same contract management
`system comprises all technical softWare components in one
`single system, Which is needed for efficiently operating the
`requested services as Well as generating the billing proce
`dure associated With the service.
`
`[0051] When further a license veri?cation program mod
`ule is used having a modular structure for each license type,
`and if those modules are sequentially operated on When
`processing an incoming request, then the additional advan
`
`ServiceNow's Exhibit No. 1006
`
`012
`
`

`
`US 2005/0071276 A1
`
`Mar. 31, 2005
`
`tage results that the inventional concept is easily to be
`extended for more license types Without being constrained to
`append much meta-logic around such neW module. Further,
`the inventional concept can be integrated in a contract
`management system that comprises a pro?le handler, a
`contract handler and a metering request handler, Wherein
`such handler components cooperate With respective
`remotely operated services, ie a pro?le service for checking
`and validating the personal identity of the requesting person,
`a contract service for checking the usage of the contract and
`a metering service for metering any service-relevant entities
`such as time of usage, amount of data transferred via
`netWork, etc., then respective parts of processing can be
`performed at locations best suited for collecting and pro
`cessing the respective type of data.
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`[0052] The present invention is illustrated by Way of
`example and is not limited by the shape of the ?gures of the
`draWings in Which:
`
`[0053] FIG. 1 is a code section representation shoWing a
`prior art SOAP request message contained in a HTTP POST
`request message;
`[0054] FIG. 2 is a code section representation shoWing the
`structure of a prior art HTTP request;
`
`[0055] FIG. 3 is a code section representation shoWing a
`detail structure of a prior art SOAP message;
`
`[0056] FIG. 4 is a code section representation shoWing the
`overall structure of a prior art SOAP message contained in
`a HTTP POST request message;
`
`[0057] FIG. 5A is a code section representation shoWing
`a section of a prior art exemplary WSDL document used for
`describing Web services;
`[0058] FIG. 5B is the continuation of FIG. 5A;
`
`[0059] FIG. 6 is a schematic representation of the rela
`tionships betWeen Service Consumer, Service Supplier and
`Service provider according to a preferred embodiment of the
`inventional method;
`[0060] FIG. 7 is a schematic representation of the main
`structural elements being used in the scenario given in FIG.
`6;
`[0061] FIG. 8 is a schematic representation of the rela
`tionships betWeen Service Consumer, Service Supplier and
`Service provider according to further preferred embodiment
`of the inventional method enriched by the inventional
`license processing component;
`[0062] FIG. 9 is a schematic representation of the main
`structural elements being used in the scenario given in FIG.
`8;
`[0063] FIG. 10 is a schematic representation illustrating
`the control How in an exemplary embodiment of a license
`processing softWare component according to the invention.
`
`DETAILED DESCRIPTION OF THE
`PREFERRED EMBODIMENT
`
`[0064] With reference to FIG. 6 a scenario is described in
`Which the service supplier abbreviated further as SS offers
`the service to the Service Consumer, abbreviated as SC. The
`
`Service Provider abbreviated as SP realiZes the main part of
`the contract management infrastructure including the main
`inventional softWare components.
`
`[0065] This results in the folloWing interactions, Which are
`implemented according to this embodiment in the respective
`program module(s) as “steps” of a respective inventional
`method used by the parties SC, SS, and SP. The steps are
`enumerated as depicted in the draWing:
`
`[0066] Step 610: SC initiates a service request in order to
`invoke a business service, Which is provided by SS. SS
`receives the request.
`
`[0067] Step 620: SS sends a service request to SP in order
`to use the contracting system and infrastructure services
`provided by the SP. In particular, in this embodiment the
`contracting system services comprise the contracting ser
`vice, and the infrastructure services are metering service and
`pro?ling service.
`[0068] Step 630: SP performs the requested contracting
`system and infrastructure services, eg veri?es that a valid
`contract is available, initiates a meter event and returns the
`status to SP.
`
`[0069] Step 640: SS performs the requested service and
`invokes SP in order to generate adequate meter events.
`
`[0070] Step 650: SS sends data representing the service
`result to SC.
`
`[0071] The implementation of step 620 is shoWn in FIG.
`7 in more detail: The service provider realiZes an application
`server, depicted With a dotted-line frame, Which contains a
`servlet 71, implementing the runtime environment for ser
`vice requests, for example a Web service runtime environ
`ment like Apache Axis.
`
`[0072] The application server also contains multiple han
`dler components denoted With reference signs 72, 74, 76.
`These handlers realiZe a local implementation of the infra
`structure components F-H, Which may be realiZed on remote
`servers for example as further Web services. The handlers
`72, 74, 76 provide local functionality needed to handle the
`communication With the remote services:
`
`[0073] A Pro?le Handler 72 uses external Pro?le
`Service 72A in order to verify the requester’s iden
`tity.
`
`[0074] A Contract Handler 74 uses external Contract
`Services 74A in order to verify the contract state and
`contract validity.
`
`[0075] A Metering Handler 76 generates adequate
`meter events (start-, end-, adhoc-, cancel events, etc).
`
`[0076] The components 71, 72, 74, 76 (servlet and han
`dlers) run in a shared memory environment and communi
`cate through shared data.
`
`[0077] The servlet 71 ensures that the handlers are
`invoked in the correct order.
`
`[0078] The infrastructure services are described next
`beloW:
`
`[0079] The Pro?le Service 72A may be basically used as
`available in above-described prior art.
`
`ServiceNow's Exhibit No. 1006
`
`013
`
`

`
`US 2005/0071276 A1
`
`Mar. 31, 2005
`
`[0080] The Pro?le Service provides access to user pro?le
`information like name, address, user-ID, etc. Depending on
`the implementation, this may be expanded to include more
`information. The Pro?le Service may be used to save, delete
`and get pro?le information.
`
`[0081] For the other services to Work correctly, all users of
`business services must have a pro?le assigned by the Pro?le
`Service. Pro?les may be created in advance by using a user
`interface or by directly editing the XML ?le that holds
`pro?les. This Pro?le Service can be replaced by any other
`identity system like Tivoli Identity Manager.
`
`[0082] The Contract Service 74A implements a prior art
`contracting management concept adapted to integrate the
`inventional licensing component.
`
`[0083] The Metering Service 76A receives meter events,
`as explained beloW, persistently stores the meter events and
`retrieves meter events upon request. According to this pre
`ferred embodiment the Metering Service may be used in
`conjunction With contract information from the Contract
`Service 74 to produce a usage report for a particular client
`using a particular service. It should be noted