Ex Parte Friesen et alDownload PDFPatent Trial and Appeal BoardDec 18, 201411344914 (P.T.A.B. Dec. 18, 2014) Copy Citation UNITED STATES PATENT AND TRADEMARK OFFICE ___________ BEFORE THE PATENT TRIAL AND APPEAL BOARD ___________ Ex parte ANDREAS FRIESEN and MICHAEL ALTENHOFEN ___________ Appeal 2012-002776 Application 11/344,914 Technology Center 2400 ___________ Before ANTON W. FETTING, BIBHU R. MOHANTY, and NINA L. MEDLOCK, Administrative Patent Judges. FETTING, Administrative Patent Judge. DECISION ON APPEAL STATEMENT OF THE CASE1 Andreas Friesen and Michael Altenhofen (Appellants) seek review under 35 U.S.C. § 134 of a final rejection of claims 1, 2, 4–19, and 21–23, the only claims pending in the application on appeal. We have jurisdiction over the appeal pursuant to 35 U.S.C. § 6(b). The Appellants invented a way of performing a dynamic update of a composed web service (Specification para 2). 1 Our decision will make reference to the Appellants’ Appeal Brief (“Br.,” filed May 23, 2011) and the Examiner’s Answer (“Ans.,” mailed August 19, 2011). Appeal 2012-002776 Application 11/344,914 2 An understanding of the invention can be derived from a reading of exemplary claim 1, which is reproduced below [bracketed matter and some paragraphing added]. 1. A method for performing a dynamic update of at least one composed web service within a web service environment, the method comprising: [1] publishing at least one goal of the composed web service within a registry of the web service environment, the at least one goal being published within a web service description of the composed web service, the composed web service relying on a set of component services linked to the at least one goal of the composed web service; [2] storing links between the set of component services and the at least one goal of the composed web service in the registry, the links being classified with respect to matching qualities of the set of component services; and [3] updating the links dynamically, using one or more processors of a computer system, in the case that any service change within the web service environment occurs by adding new links, removing existing links, Appeal 2012-002776 Application 11/344,914 3 or replacing existing links. The Examiner relies upon the following prior art: Leymann, F., Web Services Flow Language (WSFL 1.0), IBM Software Group, (May 2001), pp. 6–69 Claims 1, 2, 4–19, and 21–23 stand rejected under 35 U.S.C. § 102(b) as anticipated by Leymann. ISSUES The issues of anticipation turn primarily on whether Leymann describes the storing, classifying, and updating of the same links as in limitations [2] and [3] of claim 1, and whether all of the claims recite such limitations. FACTS PERTINENT TO THE ISSUES The following enumerated Findings of Fact (FF) are believed to be supported by a preponderance of the evidence. Facts Related to the Prior Art Leymann 01. Leymann is directed to the Web Services Flow Language (WSFL), which is an XML language for the description of Web Services compositions. WSFL considers two types of Web Services compositions: The first type specifies the appropriate usage pattern of a collection of Web Services, in such a way that the resulting composition describes how to achieve a particular business goal; typically, the result is a description of a business Appeal 2012-002776 Application 11/344,914 4 process. The second type specifies the interaction pattern of a collection of Web Services; in this case, the result is a description of the overall partner interactions. Leymann para 1. 02. Leymann describes the flow model. In the first case, a composition is created by describing how to use the functionality provided by the collection of composed Web Services. This is also known as flow composition, orchestration, or choreography of Web Services. WSFL models these compositions as specifications of the execution sequence of the functionality provided by the composed Web Services. Execution orders are specified by defining the flow of control and data between Web Services. For this reason, in this document, we will also use the term flow model to refer to the first type of Web Services compositions. Flow models can especially be used to model business processes or workflows based on Web Services. Leymann para 1.1. 03. Leymann describes global models. In the second case, no specification of an execution sequence is provided. Instead, the composition provides a description of how the composed Web Services interact with each other. The interactions are modeled as links between endpoints of the Web Services’ interfaces, each link corresponding to the interaction of one Web Service with an operation of another Web Service’s interface. Because of the decentralized or distributed nature of these interactions, [Leymann] will use the term global model in this document to Appeal 2012-002776 Application 11/344,914 5 refer to this type of Web Services composition. Leymann para 1.2. 04. Leymann describes recursive composition. WSFL provides extensive support for the recursive composition of services: In WSFL, every Web Service composition (a flow model as well as a global model) can itself become a new Web Service, and can thus be used as a component of new compositions. The ability to do recursive composition of Web Services provides scalability to the language and support for top-down progressive refinement design as well as for bottom-up aggregation. For these reasons, recursive composition has been a central requirement in the design of the WSFL language. Leymann para 1.3. 05. Leymann describes service providers. A flow model specifies its requirements for services provided by a business partner when instances are made from the model. Often, the same business partner has to perform certain activities within a flow. And, often, the business partner has to offer the execution of these activities in a particular order. This expected behavior of a potential business partner is captured by the concept of a service provider. The service provider concept allows one to specify the “role” that is expected to be played by a potential business partner. The corresponding requirements are specified through a service provider type. A service provider type is just a named set of port types. The port types collected by a service provider type may be derived from the public interface of a flow model or may be just “opaque” port types. If a port type stems from the public interface Appeal 2012-002776 Application 11/344,914 6 of a flow model, the operations of the port type “inherit” restrictions from the flow model on the validity of invocation sequences between the operations from the port type. If a port type is opaque, no such restrictions exist. In this sense, flow models as well as port types represent a “type system” for service providers. Thus, the support of port types from the public interface of another flow model will be specified (that is, the service provider is required to be of the corresponding service provider type) if the order of invocation of operations matters, and opaque port types will be specified if the order is immaterial. Note, that any mixture of opaque and “restricted” port types is allowed to be collected into a service provider type. Furthermore, by associating a set of activities of a flow model with the same service provider it is specified that at run time, operations of the same service have to be used for implementing the activities. This might be perceived as specifying “roles” that potential partners must be able to play in order to do business with the organization that specifies an actual flow model. In order to actually select a specific service provider to bind to in the actual business context (that is, an “instance” of a role), so-called locators will be used: A locator is a specification of how to find a specific service provider. It can be a static locator that binds to a fixed service provider (“always bind to my preferred ticket agent”), it can be a “mobility” locator that allows to specify the actual service provider through messages exchanged as late as when the corresponding port is to be invoked (“send the bill for the ordered Appeal 2012-002776 Application 11/344,914 7 goods to the following email address”), or it can be a query that further restricts in a declarative manner the set of possible partners playing the role needed (“bind to the provider that needs the shortest processing time”). Actual service providers can be selected and bound to at different points in time: when a flow model is instantiated, when the first of a set of activities associated with a service provider is visited by the control flow, or whenever an activity is visited by the control flow. Leymann para 3.1.1.15. 06. Leymann describes determining which operation is the activity implementation. In a first attempt, one could directly specify port type pt and operation 01 from the service provider type to interact with the service needed as implementation of activity A. From a modeler’s point of view, this would be fine: We envision that a flow modeler will interact during build time with UDDI2 (or a similar directory) searching for businesses that are supporting 2 The Universal Description, Discovery and Integration (UDDI) specifications define a registry service for Web services and for other electronic and non-electronic services. A UDDI registry service is a Web service that manages information about service providers, service implementations, and service metadata. Service providers can use UDDI to advertise the services they offer. Service consumers can use UDDI to discover services that suit their requirements and to obtain the service metadata needed to consume those services. The UDDI specifications define: SOAP APIs that applications use to query and to publish information to a UDDI registry; XML Schema schemata of the registry data model and the SOAP message formats; WSDL definitions of the SOAP APIs; and UDDI registry definitions (technical models - tModels) of various identifier and category systems that may be used to identify and categorize UDDI registrations - http://uddi.xml.org/node/96 Appeal 2012-002776 Application 11/344,914 8 implementations of services implementing various activities of the flow actually being modeled. Simply, the modeler wants to “drag” the operation of a port type found to the activity whose appropriate implementation is looked for, and “drop” it there. This corresponds in a natural manner to specifying the operation and the port type found directly as the activity’s implementation. But doing so would ignore the fact that the other goal of WSFL is to support a composition model for Web Services: A flow model should be viewable as a new stand-alone, a self- contained Web Service describing all of its interaction requirements and offers. Thus, an activity of a flow model should not link directly to the proper port type and operation that provides its implementation. Instead, a flow model should describe all of its interaction requirements with port types and operations in such a manner that the entity representing the flow model (or the new Web Service, respectively) builds a new service provider type. To achieve that, the flow model specifies as implementation of an activity an operation that is dual to the one providing the implementation proper. For example, if the activity implementation proper is a request-response operation, the dual operation specified as activity implementation is a corresponding solicit-response operation. Again, not the implementation proper but a dual operation is specified as the activity’s implementation. This dual operation may be perceived as a “proxy” for the implementation proper. Leymann para 3.5.4. Appeal 2012-002776 Application 11/344,914 9 07. Leymann describes service locators. Service providers are the units of the binding operation in flow models. Several different types of binding are possible, which are identified using the type attribute in the element. In a static binding, the actual bound service is directly specified as the value of the service attribute, referring to the WSDL or WSFL definition of the service. In a local binding, the provider of the service is specified as a locally accessible program or software component. The service attribute can be used to specify the local service if a WSDL binding is available for the local component. The local keyword is then used as a hint to the processor about the local nature of the service. In a UDDI type binding, the locator contains a UDDI query that will produce a list of candidate bindings when executed against a UDDI repository. In the mobility type binding, the information required to bind a service provider is extracted from the data exchanged in a prior interaction. Leymann para 4.4.3. 08. Leymann describes dynamic binding in UDDI binding. Because the UDDI query application programming interface (API) is defined as a Simple Object Access Protocol (SOAP) API, a UDDI query is represented by the corresponding SOAP message. This XML fragment is provided directly nested under the element. It may include two attributes, bindTime and selectionPolicy, that help control the binding process. The bindTime attribute is used to specify at what point in time the service provider is to be bound. Leymann para 4.4.3. Appeal 2012-002776 Application 11/344,914 10 ANALYSIS We are persuaded by the Appellants’ argument that the Examiner alleged, with respect to claim 1, that Leymann discloses updating the links “in the case that any service change within the web service environment occurs by adding new links, removing existing links, or replacing existing links” citing to Leymann, page 46, second bullet. However, the cite portion of Leymann is directed to one binding type of a locator whereby “the locator contains a UDDI query that will produce a list of candidate bindings.” The Examiner had previously equated the locator to the links between the component services and the at least one goal, which Appellants vigorously deny. Assuming, arguendo, that this is the case, producing a list when a query is executed does not teach “updating the links dynamically . . . by adding new links, removing existing links, or replacing existing links” as recited in Appellants’ claim 1. Br. 16. (Emphasis omitted.) The difficulty for the Examiner is that limitation [3] recites updating the links rather than simply updating links. Thus, claim 1 requires that the very links recited as being stored in limitation [2] be the links that are updated. The Examiner relies upon Leymann’s locators as links so as to be able to show classification of links. Ans. 16. But the Examiner relies upon a UDDI query to result in dynamic locator binding for the link updates. Ans. 16–17. See FF 07–08. Such links in the form of query results are not the locator links that are shown as being classified. Independent claims 10, 19, and 21 each has similar limitations. Appeal 2012-002776 Application 11/344,914 11 Claim 15 reads as follows. A system comprising: an association storage as part of a web service environment containing a plurality of services to store associations between goals published within at least one web service description of a composed web service and potential component services containing service capabilities which match with those goals, the composed web service relying on a set of component services which are linked with the at least one goal of the composed web service, the links being classified with respect to matching qualities of the set of component services. Claim 15. Here, we agree with the Examiner that Leymann describes the claimed subject matter. Claim 15 does not share the limitation of links that are stored, classified, and updated as the remaining independent claims have. Appellants do not argue claim 15 separately. We adopt the Examiner’s findings and analysis from Answer 12–13. CONCLUSIONS OF LAW The rejection of claims 1, 2, 4–14, 19, and 21–23 under 35 U.S.C. § 102(b) as anticipated by Leymann is improper. The rejection of claims 15–18 under 35 U.S.C. § 102(b) as anticipated by Leymann is proper. Appeal 2012-002776 Application 11/344,914 12 DECISION The rejection of claims 1, 2, 4–14, 19, and 21–23 is reversed. The rejection of claims 15–18 is affirmed. No time period for taking any subsequent action in connection with this appeal may be extended under 37 C.F.R. § 1.136(a). See 37 C.F.R. § 1.136(a)(1)(iv) (2011). AFFIRMED-IN-PART Ssc Copy with citationCopy as parenthetical citation