T 1046/06 (Discovering web services/PHILIPS ELECTRONICS) of 23.1.2009

Summary of Facts and Submissions

I. This appeal is against the decision of the examining division to refuse the application on the ground that the subject-matter of claim 1 of the main and auxiliary requests was obvious (Article 56 EPC 1973) over US-A-6 163 316 (D1) and "UDDI Technical White Paper", XP 002230398, 6 September 2000, pages 1-12 (D2).

II. In the statement setting out the grounds of appeal, the appellant requested that the decision under appeal be set aside and that a patent be granted on the basis of claims 1 to 14 filed therewith. The appellant contested the examining division´s finding of lack of inventive step of the similar refused requests.

III. In the communication accompanying the summons to oral proceedings, the Board summarised the issues to be discussed and expressed the provisional view that the subject-matter of the independent claims did not involve an inventive step. In this context, the Board considered the UDDI specification disclosed in D2 to be a better starting point than document D1. The Board also indicated that it was not convinced by the appellant's arguments relating to document D2 because they involved features that were not in the claims. Moreover, the Board referred to the following document:

D2´ "UDDI Programmer´s API Specification", 6 September 2000, pages 1-60, (like D2, this is one of the original UDDI specification documents from the year 2000, which can be retrieved e.g. via http://xml.coverpages.org/UDDI_Programmers_API_Specification.pdf).

IV. In a response, the appellant stated that he withdrew the present application on the condition that "any fee" was refunded. In a further letter, the appellant informed the Board that he would not attend the oral proceedings, and requested that the case be decided on the state of the file as it stood.

V. At the end of the oral proceedings, which took place in the appellant's absence, the Chairman announced the Board´s decision.

VI. Claim 1 of the single request reads as follows:

"A method for automatically discovering web services comprising querying a known UDDI server address containing a list of web services, identifying from said list suitable web services that are compliant with a particular web service standard and that conform to a set of taxonomies, the taxonomies standardised for the particular web service standard, and automatically downloading at least one machine readable description of a web service, said querying comprising transmitting a query including an element specifying the set of taxonomies to which said service must conform, and wherein said querying is initiated independently of user intervention."

VII. In the statement of grounds, the appellant argued essentially as follows with respect to D2:

D2 was a standard directed at business-business solutions and e-commerce. It disclosed the process to enable a program to access a web service using UDDI:

1. The programmer used the UDDI business registry to locate the businessEntity information registered for the appropriate business partner advertising the Web service.

2. The programmer selected a particular bindingTemplate and saved this for later use.

3. The programmer prepared the program based on the knowledge of the specifications for the Web service. This information could be obtained by using the tModel key information contained in the bindingTemplate for a service.

4. At runtime, the program invoked the Web service as planned using the cached bindingTemplate information (as appropriate).

In the general case, assuming the remote Web service and the calling program each accurately implemented the required interface conventions (as defined in the specification referenced in the tModel information), the calls to the remote service would function successfully (D2, page 8, section 'The UDDI Invocation model')

In the present invention, the process was substantially different:

1. A standards body standardised a web service interface suitable for a class of CE devices.

2. This service was registered with a UDDI node and was assigned a UUID (universally unique identifier) for that standard interface (using the UDDI save_tModel API).

3. Service providers produced implementations of this standard interface. They registered the new service using the save_service API, assuming that the business itself had already been registered with UDDI. The enclosed bindingTemplate would contain a reference to the UUID of the tModel registered in step 2. At this stage they might also assign further standardised categorisations to their service (e.g. a retail service could register that it was based in London and offered pet food). The categorisations were added using the categoryBag sub-element of the businessService element.

4. A CE device was designed which was able to use the standardised web interface.

5. After being sold, the device queried a UDDI node to find services that supported this interface. To do this the find_business API was used containing just a tModelBag argument with a reference to the required tModel. A list of services was returned to the device, which could then be further refined automatically (based on machine-readable service descriptions) or by the user (based on brand preferences, recommendations, etc. - description page 6, lines 11-31).

In other words, D2 taught a (user/programmer-driven) method for associating a client program with a published UDDI web service, by means of the user identifying the (tModel) specification of the service and adapting the program to be compatible therewith.

In contrast, the present invention taught use of a standardised web service interface (identified by its tModel) which was then implemented by various web services and registered with UDDI; these services were then identified by compatible CE products designed to use the standardised web interface. The tModel behaved as a technical fingerprint that formally indicated the compliance of the service (description page 8, lines 6-8).

Reasons for the Decision

1. The appeal complies with the requirements referred to in Rule 65(1) EPC 1973 and is therefore admissible.

Conditional withdrawal of application

2. The appellant's statement concerning withdrawal of the application relied on the condition that "any fee" be refunded. However, the condition cannot be met since there is no legal basis in the EPC for reimbursing "any fee" and all fees paid were due, with the result that the present application must be considered to be still pending.

The invention

3. The application relates to finding automatically available web services, e.g. a grocery shopping service, or a TV service from networked consumer electronics (CE) devices (fridge or set-top box, respectively).

4. Standard protocols (SOAP, XML, and HTTP) that enable CE devices to access web services are known. Figure 1 of the application shows an example where the CE device 1 (a digital radio in the embodiment) sends a request (e.g. SOAP request) 4 via the internet 3 for information (e.g. about a particular song) to a server 2 that is known to have the information. The server responds with a structured response (e.g. SOAP response) 5 containing the desired information. The problem with this is that the user must know about the existence of the server 2 in order to get the information. It is possible to search for new services, or have third parties or manufacturers send new software to the users´ devices. However, it is difficult to find new services automatically, i.e. without browsing or requiring keyboard input (see pages 1 and 2 of application).

5. The application explains (Figure 2, pages 2 to 5) a solution to this using UDDI (Universal Description, Discover and Integration), which is a well known specification for discovering web services (see below). Available services are stored on a UDDI server 10 at a known address. The CE device sends it a structured UDDI query 11 requesting available services (e.g. for services that provide information on radio broadcasts). The server responds with a structured UDDI response 12 giving services that satisfy the criteria of the query, e.g. available on servers 13. The CE device may now request the desired information from these servers in the manner described above. When a service provider offers a new service they publish the details on the UDDI server.

6. A problem with general UDDI queries is that the search for the services is not focussed and produces too many results (page 8, lines 9 to 24). The solution to this problem is presented as standardising a set of taxonomies to categorise the relevant services (e.g. Figure 5, page 8, lines 25 to 32 for TV Anytime services). The taxonomies can be included in the search criteria to limit the number of results. The application gives an example (page 9) of a set-top box trying to create an electronic guide (EPG) in French using TV Anytime data.

Inventive step

7. The examining division considered that D1 was the closest prior art, possibly because it related to an electronic programming guide, which is the subject of the example in the description. However, the method of claim 1 is not limited to any particular type of client, in particular not small consumer electronic (CE) devices. In fact, it relates almost entirely to aspects of the UDDI specification. Thus the Board considers that the UDDI specification disclosed in D2 and explained more fully in D2´is a better starting point.

8. In particular the UDDI system provides:

A method for discovering web services (see e.g. D2, page 1, first two paragraphs) comprising querying a known UDDI server address containing a list of web services (Figure 3 and page 7, last paragraph - querying the UDDI registry and page 8 - "The Inquiry API"), identifying from said list suitable web services that are compliant with a particular web service standard and that conform to a set of taxonomies, the taxonomies standardised for the particular web service standard (page 2, third last paragraph - so called "yellow page" information and page 7, third last paragraph and Appendix A, top right box - "tModel"), and downloading at least one machine readable description of a web service (the result of the query), said querying comprising transmitting a query including an element specifying the set of taxonomies to which said service must conform (the "<categoryBag>" element, see Appendix A, middle box and D2', page 16 - "find_business" message - cf. page 10, lines 5 to 6 of the application).

9. In the Board's view, the subject-matter of claim 1 differs from the UDDI system in that the discovery and downloading is performed "automatically" and "independently of user intervention", the latter being the feature added in appeal. However, these are merely desiderata without any further details of how they are actually achieved. Given that the queries are provided in the form of an application programming interface (API) that are designed to be used in some form of computer program, the Board considers that the mere idea that the queries should be performed "automatically" is self-evident.

10. Accordingly, the Board judges that claim 1 (and corresponding apparatus claim 6) does not involve an inventive step (Article 56 EPC 1973).

11. The bulk of the appellant's arguments in the grounds of appeal deal with D1, which as mentioned above, the Board does not consider to be as relevant as D2. As communicated to the appellant (see point III, above), the Board does not consider the arguments that relate to D2 (see point VII, above) to be persuasive because they concern specific features of the invention that are not in claim 1, namely CE devices, specific API calls and standardising processes.

12. There being no further requests, it follows that the appeal must be dismissed.

ORDER

For these reasons it is decided that:

The appeal is dismissed.