T 0825/13 (Java virtual machine/ORACLE AMERICA) of 20.3.2018

Summary of Facts and Submissions

I. The applicant (appellant) appealed against the decision of the Examining Division refusing European patent application No. 01937489.1, filed as international application PCT/US01/15946 and published as WO 01/95153. The application claims a priority date of 2 June 2000.

II. The Examining Division decided to refuse the application for lack of inventive step (Articles 52(1) and 56 EPC) of the subject-matter of independent claim 1 of the sole request then pending over the prior art disclosed in the following documents:

D4: Anonymous: "Disk Drive with Embedded Hyper-Text Markup Language Server", IBM Technical Disclosure Bulletin, vol. 38, no. 12, page 479, published in December 1995;

D1: Lowe, Jim: "How Java servlets can replace CGI scripts -- for ease, performance & more", NETSCAPEWORLD, pages 1 to 3, retrieved from the Internet and considered by the Examining Division to have been published in May 1997.

In the written proceedings the Examining Division cited, inter alia, the prior-art document:

D5: Chintalapati M. et al.: "Web Server and Browser Design Considerations", Annual Review of Communications, National Engineering Consortium, Chicago, IL, US, vol. 50, pages 639 to 656, 1997.

III. In the statement of grounds of appeal, the appellant maintained its sole substantive request.

IV. In a communication under Article 15(1) RPBA accompanying a summons to oral proceedings, the Board, inter alia, expressed its provisional opinion that the subject-matter of claim 1 of the sole request lacked inventive step when starting from document D4 or, alternatively, from a well-known Java Virtual Machine (JVM) as prior art. It also raised concerns in view of the requirements of Article 84 and 123(2) EPC.

Moreover, as evidence that document D1 was publicly available at the priority date of the application, the Board cited the following document:

D7: US 5,928,323 A, published on 27 July 1999.

V. In reply to the Board's summons, the appellant submitted a new main request and a new auxiliary request and maintained the request considered in the contested decision as an additional auxiliary request. It also filed a procedural request that the case be remitted if the Board's objections for added subject-matter and lack of clarity were not resolved at the oral proceedings. The appellant argued in detail why the newly submitted requests resolved the Board's objections.

VI. In response to the appellant's submissions, the Board informed the appellant of its provisional opinion that the objections for added subject-matter had been overcome by the amendments and that only one remaining clarity issue might need to be discussed. Moreover, in response to the appellant's arguments in support of inventive step, the Board argued why it still considered its negative opinion to be justified and drew the appellant's attention to the following further prior-art documents:

D8: "CICS* on the Internet", IBM Technical Disclosure Bulletin, Vol. 38, No. 12, December 1995, page 549;

D9: US 5,996,010 A, published on 30 November 1999.

VII. With a letter dated 29 January 2018, the appellant maintained all requests, submitted arguments in reply to the Board's communication and informed the Board that it would not be attending the oral proceedings.

VIII. Oral proceedings were held as scheduled, in the absence of the appellant. At the end of the oral proceedings, the chairman declared the debate closed and announced that the Board's decision would be given in writing.

IX. The appellant's final requests were that the contested decision be set aside and that a patent be granted on the basis of the main request, the auxiliary request or the additional auxiliary request. It also requested that the case be remitted if the Board's objections for added subject-matter and lack of clarity were not resolved at the oral proceedings.

X. Claim 1 of the main request reads as follows:

"A computer implementing a virtual machine (102) configurable to function as a web server, the virtual machine comprising:

a request handler worker (202) for handling an incoming query (106) relating to an operational state of the virtual machine;

a plurality of services (212) wherein a service performs operations for replying to the incoming query; and

an operations worker (214) for generating output containing a reply (218) to the incoming query, using at least one of the plurality of services (22), wherein the reply provides state information regarding the operation of the virtual machine (102), and wherein the reply is an HTTP response comprising HTML or XML pages; and

a request data structure (204) for transferring data between the request handler worker and the operations worker, the request data structure having a service pointer area (210) containing a pointer to one of the plurality of services (212) to be used for deriving the reply to the incoming query, a response buffer area (208), and a segment query area (206)."

Claims 2 to 14 are directly or indirectly dependent on claim 1.

Claim 15 reads as follows:

"A computer-implemented method for a virtual machine (102), configured to function as a web server, the method comprising:

receiving an incoming query from a browser;

a request handler worker (202) in the virtual machine handling the incoming query (106) relating to an operational state of the virtual machine;

transferring data between the request handler worker and an operations worker in the virtual machine using a request data structure having a service pointer area (210) containing a pointer to one of a plurality of services (212) to be used for deriving a reply to the incoming query, a response buffer area (208), and a segment query area (206);

the operations worker (214) generating output containing the reply (218) to the incoming query, using at least one of the plurality of services (22), wherein the reply provides state information regarding the operation of the virtual machine (102), and wherein the reply is an HTTP response comprising HTML or XML pages; and

transmitting the reply to the browser."

Claims 16 to 23 are directly or indirectly dependent on claim 15.

Claim 24 reads as follows:

"A computer-readable medium containing programmed instructions arranged to handle an incoming query (106), in a virtual machine (102) configurable to function as a web server, the computer-readable medium including programmed instructions for performing the method of any of claims 15 to 23."

The auxiliary requests are not relevant to the present decision.

XI. The appellant's arguments relevant to the decision are discussed in detail below.

Reasons for the Decision

1. The appeal complies with the provisions referred to in Rule 101 EPC and is therefore admissible.

The invention

2. The application relates to a Java virtual machine that can function as a web server in order to make information about an operational state of the Java virtual machine accessible in a format suitable for a web browser. An incoming query for the information (e.g. a Uniform Resource Locator - URL) is parsed by a request handler worker in order to determine a service useful for generating the reply to the query. The request handler worker passes the request via a request data structure to an operations worker for providing the reply.

Main request - admission

3. Since the amended claims of the main request constitute a legitimate response to the objections raised for the first time in the Board's preliminary opinion, the Board admits this request into the appeal proceedings (Article 13(1) RPBA).

Main request

4. Claim 1 of the main request relates to a "computer implementing a virtual machine configurable to function as a web browser", the virtual machine comprising the following features, as itemised by the Board:

(a) a request handler worker for handling an incoming query relating to an operational state of the virtual machine;

(b) a plurality of services wherein a service performs operations for replying to the incoming query;

(c) an operations worker for generating output containing a reply to the incoming query, using at least one of the plurality of services, wherein the reply provides state information regarding the operation of the virtual machine, and wherein the reply is an HTTP response comprising HTML or XML pages;

(d) a request data structure for transferring data between the request handler worker and the operations worker, the request data structure having a service pointer area containing a pointer to one of the plurality of services to be used for deriving the reply to the incoming query, a response buffer area, and a segment query area.

Main request - clarity and added subject-matter

5. The appellant's amendments overcome the objections for lack of clarity and added subject-matter raised by the Board.

6. The wording "wherein the reply is an HTTP response comprising HTML or XML pages" in feature (c) is based on the original description, page 7, lines 14 to 15, page 8, lines 4 to 5, and page 13, lines 14 to 15.

6.1 The wording "a service pointer area containing a pointer to one of the plurality of services to be used for deriving the reply to the incoming query" in feature (d) is based on originally filed claim 19 and the description, page 9, lines 21 to 22, and page 11, lines 4 to 5.

6.2 In its preliminary opinion, the Board expressed doubts about the clarity of certain expressions in the claims of the then pending sole request.

In response the appellant has clarified all of these expressions in the present main request, except for the expression "segment query area". In its letter of 11 December 2017, the appellant submitted that it had addressed the Board's concerns by amending this expression to "query segment area", but the main request has not in fact been so amended. However, as the Board considers the proposed amendment to be clear and as the failure to amend the submitted claims of the main request in this manner appears to be a mere oversight by the appellant, the Board interprets the expression "segment query area" for the following assessment of inventive step in the sense of "query segment area", which is consistent with the interpretation it provided in its preliminary opinion. Since the appellant has requested that the case be remitted for further prosecution if the Board's fresh objections for lack of clarity are not resolved, the Board considers that in the present case, where the appellant would have overcome an objection for lack of clarity by an amendment which, although intended, it did not submit as a consequence of an apparent oversight, it is appropriate to remit the case to the department of first instance for dealing with this remaining issue, if all other objections are successfully resolved.

Main request - inventive step

7. Starting point for the assessment of inventive step

7.1 The Examining Division started its assessment of inventive step directly from document D4, a single page publication in the IBM Technical Disclosure Bulletin. This document is of a very general nature as it concerns user interfaces for computer components, both hardware and software, but does not refer to a Java virtual machine. As the invention concerns a Java virtual machine, the Board considers that D4 is not an appropriate starting point towards the invention.

7.2 According to the application, the starting point for the invention was that applications were increasingly written in the Java language and used a Java virtual machine (description, page 1, lines 12 to 14). Hence, the demand for improving the development life cycle of a Java application and improving the efficiency of a Java application became imperative. Getting a better understanding of the performance of the Java virtual machine was a step in this direction. However, as acknowledged in the field, Java virtual machines were seen as black boxes, i.e. opaque software components that performed a crucial function but whose internal states were generally inaccessible to the users (page 1, lines 19 to 22). By using a debugging protocol, it was possible to ask the virtual machine questions about its state without interfering with its other operations (page 1, lines 25 to 27). According to the application, most users would prefer to have more detailed, low-level information about the state and performance of the virtual machine (page 2, lines 7 to 8).

In view of the above, the Board considers a well-known Java virtual machine (see application, page 1 and page 13, lines 6 to 9) to be the best available starting point for the assessment of inventive step in the present case.

8. Objective technical problem

A virtual machine according to claim 1 is configured to function as a web server which processes an incoming query relating to an operational state of the virtual machine. In the appeal proceedings, the appellant argued that the skilled person was interested in obtaining or accessing information about the operational state of a Java virtual machine. Hence, when starting from a well-known Java virtual machine, the objective problem to be solved can be formulated as how to obtain information about the operational state of the Java virtual machine.

9. Assessment of inventive step

9.1 Document D4 teaches the use of standard web browsers as platform and system independent user interfaces for information sources other than those directly associated with the world wide web and the internet (D4, first and second paragraph). Such information sources can be computer components, both hardware and software, which generate HTML (Hypertext Markup Language) descriptions of their current configurations or state (D4, second paragraph). These descriptions can then be either viewed directly by a web browser by importing the HTML description from the file system or exported via communication facilities, including the internet (D4, second and third paragraph).

9.2 The Board interprets document D4 as teaching embedding an HTML server functioning as a web server for remote HTTP (Hypertext Transfer Protocol) requests into computer components in order to obtain their state or configuration.

9.2.1 The appellant contested that document D4 taught a web server. It mentioned neither a web server nor HTTP communications. The proposed HTML server would instead operate as a (possibly remote) file server.

9.2.2 The Board considers that D4 emphasises the use of platform and system independent standard web browsers for creating user interfaces. While it is true that D4 discloses that a browser can access generated HTML documents locally from the file system without the need to connect to a network communications facility, it also discloses remotely accessing the generated HTML document via the internet. In the Board's opinion, at the priority date, the skilled person interpreted remote access via the internet from a standard web browser to an embedded HTML server as meaning remote access via the HTTP protocol. This means that the skilled person understood that the HTML server disclosed in document D4 functioned as a web server. This understanding of an HTML server as a web server also corresponds to normal use of this term at the priority date, as evidenced by documents D8 and D9 (see D8, Figure and page 549, last sentence; D9, Figures 6 and 8 and column 13, lines 1 to 5).

9.3 The appellant argued that, in view of the many potential avenues for addressing the technical problem, it would not be obvious for the skilled person to read or even locate document D4, as it was entitled "Disk Drive with Embedded Hyper-Text Markup Language Server" and as a Java virtual machine was radically different from a disk drive, which was hardware rather than software (see the appellant's letter dated 11 December 2017, point 6).

9.4 The Board considers that the technical teaching rather than the title of a document is decisive for the question whether the skilled person faced with a technical problem would consider it. In the present case, the technical teaching of D4 addresses the creation of user interfaces for accessing the current configuration or state of hardware or software components (D4, second paragraph). D4 lists databases and operating systems as specific examples of software components to which its teaching is applicable, but does not mention a virtual machine. Hence, the Board has doubts that the skilled person, starting from a Java virtual machine, would have consulted this document and would have recognised that the solution proposed in D4 could also be applied to access the operational state of a Java virtual machine.

9.5 Even if the skilled person had decided to follow the teaching of document D4, he would have had to implement the solution in the Java virtual machine, i.e. implement a web server embedded in it. As document D4 does not contain any guidance on implementing a web server, the skilled person would then have to consider known web server implementations to develop a solution.

9.6 According to the contested decision, point 2.5.2, the features of claim 1 relating to web-server implementation, i.e. the request handler worker according to feature (a) of claim 1, the plurality of services according to feature (b), the operations worker according to feature (c), and the request data structure according to feature (d), "relate to nothing more than the standard structure of a conventional html server, as exemplified by document D1". Hence, after examining the public availability of document D1, the Board will then assess below whether features (a) to (d) of claim 1 do indeed correspond to a standard structure of a conventional web server, which the skilled person could have implemented at the priority date without the exercise of inventive skill.

9.7 As evidence that document D1, an internet disclosure, was publicly available at the priority date of the present application (2 June 2000), the Board introduced document D7 into the proceedings. This document, which was itself published before the priority date and is hence prior art, cites document D1 (see front page, right-hand column, lines 2 to 5). Thus, the Board recognises D1 as prior art for the present case and notes further that this was not disputed by the appellant.

9.8 The Board agrees with the Examining Division that the request handler worker according to feature (a) of claim 1 can be regarded as a worker thread receiving a URL request as disclosed in D1 (page 1, last paragraph, to page 2, first paragraph).

9.9 In the web server described in document D1 (page 2, first paragraph), all standard web server operations (file retrieval, Common Gateway Interface, server-side includes, image-mapping and administration) are performed by a series of servlets. Hence, these servlets implement a plurality of services performing operations for replying to the incoming query (see feature (b) of claim 1). Moreover, such a servlet functions as an operations worker for generating a reply to the incoming HTTP request. The reply would then normally comprise generated HTML as disclosed in D4 (see page 479, second paragraph). Hence, the skilled person would arrive, when embedding the web server proposed by D4 into a Java virtual machine, at feature (c) of claim 1 without exercising any inventive skill.

9.10 Document D1 discloses that the worker thread dispatches the HTTP request to the appropriate servlet (page 1, last paragraph, to page 2, first paragraph). This implies that some data structure is used to pass the received request from the worker thread to the servlet and to pass the result back. However, no details of this data structure are disclosed.

9.11 In section 5.2 of the statement of grounds of appeal, the appellant argued that, according to D1, page 1, last line, to page 2, first line, a work thread dispatches the received request to the "appropriate servlet" (emphasis added). The need to route a client request to an "appropriate servlet" suggested that the servlets in D1 would be specialised to a particular task.

The Board agrees with this reading of D1. As the request data structure according to feature (d) refers to a service pointer area providing the operations worker with a pointer to one of the plurality of services to be used for deriving the reply to the incoming query, the claimed operations worker is not specialised in the same way as the servlets of D1. It follows that the claimed implementation differs from the implementation of a web server known from document D1. Hence, the Examining Division's reasoning that the differences concerning the implementation of a web server related to "nothing more than a standard structure of a conventional html server, as exemplified by document D1" is not convincing as D1 does not teach the claimed web server implementation. Moreover, document D1, which is not a textbook and which only briefly describes details of one particular commercial web server implementation, does not provide sufficient evidence to establish the "standard structure of a conventional html server".

9.12 In summary, the Board is not convinced that the skilled person trying to embed the web server implementation of document D1 in a Java virtual machine would arrive at the combination of features (a), (b), (c) and (d) without exercising inventive skill.

9.13 During the appeal proceedings, the Board cited documents D7 and D9 as further examples of web server implementations.

9.13.1 D9 discloses in column 8, lines 22 to 54, details of the functioning of the HTML server: a task manager, upon receiving an incoming request, spawns a request manager which is dedicated to managing the received request. The request manager is central to the HTML server, and interacts with the response manager, the URL dictionary and a number of execution modules to process the request. The execution modules include a head and entity body parser for parsing the request (D9, column 8, line 59, to column 9, line 43).

D7 discloses in Figures 3 and 4 and column 3, lines 1 to 6, that a standard web server implementation is modified to include a server acceptor thread, a connection queue, a pool administrator, a thread pool, servlets, a servlet map, a security administrator, and boundary servlets. The server acceptor thread is used to process each new HTTP request (D7, column 3, line 57, to column 4, line 8). Once a request is received, the server acceptor thread dispatches the request to a connection queue (D7, column 4, lines 5 to 36). A thread retrieves a request from the connection queue and maps the request to a servlet name (D7, column 4, lines 37 to 58). The servlet may be specified by a part of the requested URL, in which case the mapping process is direct. Otherwise, some translation process may be required to identify which servlet will be able to service the request. The mapping operation may be performed in either of the following ways: a server administrator may specify that some kinds of client request always map to a particular servlet or that part of the client request is the name of the servlet, as found in an administered servlets directory.

9.13.2 The Board considers that documents D7 and D9 neither disclose nor suggest the specific request data structure specified in feature (d) of claim 1.

9.14 In the written proceedings, the Examining Division introduced document D5, which describes known web servers. It discloses on page 640, right-hand column, paragraph 6, a multi-threaded implementation of a web server. However, D5 does not disclose or hint at the request data structure of feature (d).

9.15 Moreover, none of the further prior-art documents on file is directed at solving the problem of accessing the operational state of a Java virtual machine via a web server or discloses a web-server implementation comprising the claimed request data structure.

9.16 In summary, the Board finds that even if the skilled person, starting from a well-known Java virtual machine, were to consider the document D4, there is insufficient evidence on file to convincingly demonstrate that he would arrive at the claimed implementation without the exercise of inventive skill. It follows that the subject-matter of claim 1 meets the requirements of Article 52(1) EPC in combination with Article 56 EPC.

This assessment applies mutatis mutandis to the method of independent claim 15, which corresponds to the computer of claim 1 in method terms with additional steps of receiving the query and transmitting the reply, and to the computer readable medium of claim 24, which includes programmed instructions for performing the method of, inter alia, claim 15. The subject-matter of the dependent claims also comprises the inventive features by virtue of those claims' dependency on the independent claims. Thus the subject-matter of the dependent claims is also inventive.

Conclusion

10. The claims of the present main request comply with the provisions of the EPC, except that the expression "segment query area" lacks clarity (Article 84 EPC). This expression still needs to be clarified by amendment to "query segment area" to bring it into conformity with the appellant's written submissions (see point 6.2 above). Moreover, a typing error in claim 7 (which refers erroneously to "in index" instead of "an index") needs to be corrected. Finally, as the claims have undergone substantial amendments, the description and drawings may need to be adapted to the claimed subject-matter before a patent can be granted.

Order

For these reasons it is decided that:

1. The decision under appeal is set aside.

2. The case is remitted to the department of first instance for further prosecution.