T 0970/13 (Flexible request-response cycles/SAP) of 23.11.2018

European Case Law Identifier: ECLI:EP:BA:2018:T097013.20181123
Date of decision: 23 November 2018
Case number: T 0970/13
Application number: 03005712.9
IPC class: G06F 9/46
Language of proceedings: EN
Distribution: D
Download and more information:
Decision text in EN (PDF, 301 KB)
Documentation of the appeal procedure can be found in the Register
Bibliographic information is available in: EN
Versions: Unpublished
Title of application: Method and computer system for enabling flexible request-response cycles
Applicant name: SAP SE
Opponent name: -
Board: 3.5.06
Headnote: -
Relevant legal provisions:
European Patent Convention 1973 Art 56
Keywords: Inventive step - (yes)
Catchwords:

-

Cited decisions:
-
Citing decisions:
-

Summary of Facts and Submissions

I. The appeal is directed against the decision of the examining division, dated 10 December 2012, to refuse application No. 03005712.9 for lack of inventive step using the following documents:

D1 |EP 1 156 415 A2. |

D2 |E. Gamma et al.: "Design Patterns. Elements of Reusable Object-Oriented Software", Addison-Wesley, Boston/USA, 1995, pages 293-303, XP2460182.| | |

II. A notice of appeal was received on 7 February 2013. The appeal fee was paid on the same day. A statement of grounds of appeal was received on 21 February 2013.

III. The appellant requests that the decision be set aside and the case be remitted to the first instance with the order to grant a patent based on the main request of the appealed decision, filed on 18 October 2012, or the first auxiliary request of the decision, filed during oral proceedings before the examining division and labeled "even further new request".

The further application documents are: description pages 1, 4-27 as originally filed; page 2 filed on 29 October 2004; page 2a filed on 18 October 2012; page 3 filed on 17 June 2009 and drawing sheets 1-7 as originally filed.

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

"1. A method (400) for event handling on a client (901) in a computer system (999), wherein the client (901) runs a browser (201) to access an application (200) that is running on a server (900) of the computer system (999), the client (901) communicating with the server (900) over an asymmetric protocol, comprising the steps:

the browser (201) sending (410) a request (300) to the application (200), wherein the request (300) comprises a browser component request (510) that originates in a first browser component (BC1) and a further browser component request (520) which is generated at a further browser component (BC3) and which is buffered with the browser component request (510) in a request queue (111) and bundled with the browser component request (510) in the request (300), wherein the further browser component request (520) is generated in response to a client event (515) generated by the first browser component (BC1), wherein the client event (515) is part of a client event cascade that is triggered by a triggering action for the browser component request (510) and includes further client events that can affect further browser components; and

in response to the request (300) the browser (201) receiving (420) from the application (200) a server response (310), wherein a first application component response (540) that is directed to the first browser component (BC1), a second application component response (550) that is directed to a second browser component (BC2), and a further application component response (522) that is directed to the further browser component (BC3) and that is generated by a further application component (AC3) in response to the further browser component request (520) are buffered in a response queue (110) and bundled into the server response (310);

wherein the server (900) uses dependencies that are defined by the application (200) for launching a server event cascade and wherein the application (200) determines which of the browser components (BC1, BC2) are effected by the server event cascade and sends the corresponding application component responses (540, 550) to the browser (201)."

V. Claim 6 is an independent server-side method claim which corresponds exactly to the client-side method claim 1.

VI. Independent client-side device claim 11 reads as follows:

"11. A client (901) comprising:

a browser (201) configured to perform a method as claimed in claim 1."

VII. Independent server-side device claim 15 reads as follows:

"15. A server (900) comprising:

an application (200) operable to perform a method as claimed in claim 6."

VIII. Independent computer program product claims 19 and 20 read as follows:

"19. A computer program product comprising instructions that when loaded into a memory of a client (901) cause at least one processor of the client (901) to perform the steps according to any one of the claims 1 to 5."

"20. A computer program product comprising instructions that when loaded into a memory of a server (900) cause at least one processor of the server (900) to perform the steps according to any one of the claims 6 to 10."

IX. In view of the board's decision, the claim text of the auxiliary request is irrelevant.

Reasons for the Decision

1. Summary of the invention

1.1 The claimed invention relates to the communication between a (web) browser program 201 on a client computer 901 and a (web) application 200 on a server computer 900 (see original description, page 4, lines 20-24). It can best be seen in figure 4 (see also page 16, second para­graph to page 18, second para­graph): the user performs a triggering action (e.g. a mouse click; page 16, fourth paragraph, first sentence and page 7, lines 29-34) on a first (graphical) browser component BC1 (e.g. a button). The browser 201 then generates a browser component (BC) request 510 to be sent to the server 900 and buffers it in its request queue 111 in order to group it with other requests triggered by the same user action. This BC request 510 not only concerns BC1, but also BC2 (another browser component) which is somehow related to BC1.

1.2 The action also triggers the browser to generate a so-called client event 515 (which is part of a "client event cascade") directed to a further browser component BC3 in the same browser (page 16, lines l5-21). This means that also BC3 is related to BC1. In response to the client event sent from BC1 to BC3, the latter generates a further BC request 520 (lines 21-23). This BC request (520) is also buffered in the request queue 111 of the browser and then sent together with the first BC request 510 as a "bundled" request 300 (page 16, line 28 to page 17, line 2) to the server for its applica­tion 200.

1.3 In response to the (bundled) request, three so-called application components (AC1, AC2, AC3; corresponding to the three browser components BC1, BC2 and BC3 above) generate application component (AC) responses (540, 550, 522), which are again buffered in a so-called response queue 110 in the server and then sent as a "bundled" server response 310 to the browser (page 17, lines 11-33).

2. Overview of the board's decision

2.1 The appealed decision is flawed, since the combination of D1 and D2 does not yield the claimed invention.

2.2 The subject-matter of claim 1 of the main request is inventive (Article 56 EPC 1973), since it produces a technical effect in a non-obvious way.

3. Original disclosure

The examining division did not raise any objections under Article 123(2) EPC in its decision and the board concurs that there was no reason to do so, at least with respect to the claims of the main request.

4. Inventiveness

4.1 The appealed decision (3.1-3.1.4) argues that a combination of D1 and D2 would lead to the subject-matter of claim 1 of the main request.

4.2 The board agrees with the decision that D1 is well-suited to serve as the closest prior art, but disagrees with the decision (3.1, middle of page 5 to top of page 6) that D1 disclosed a server event between (server-side) application components (AC1->AC2) so that a response (550) for a corresponding (client-side) browser component (BC2) is produced which itself has not sent a request to the server beforehand (see claim 1 and figure 4).

4.3 The passage in D1 ([32]) indicated in the decision only discloses one (server-side) application component which corresponds to a browser component ([32], first sentence):

"In contrast to "ACTIVEX" controls, a server-side control object in an embodiment of the present invention, being specified in a dynamic content resource 124, logically corresponds to a user interface element that is displayed on the client." (emphasis added)

This "server-side control object" of D1 indeed corresponds to the application component AC1 of the claim.

4.4 The other server-side component in [32], cited in the decision as corresponding to AC2 and as receiving a server event from AC1 ([32], last sentence: "A server-side control object in an embodiment of the present invention can also raise events to a server-side "ACTIVEX" object used to implement a stock look-up application on the server.", emphasis added), is however an ACTIVEX control which implements for example a database application ("stock look-up") and thus has no corresponding (client-side) browser component. See also [31], last but one sentence:

"Server-side ACTIVEX components (not shown) are COM-based components that may be implemented on a server to perform a variety of server-side functions, such as providing the server-side functionality of a stock price look-up application or database component."

4.5 This shows that D1 does not disclose server events between two application components, each corresponding to a browser component. Thus there can also be no response in D1 to the (client-side) browser component corresponding to the application component receiving the server event (i.e. the ACTIVEX component which does not have a corresponding browser component).

4.6 Thus, the combination of D1 and D2 as described in the decision does not lead to the subject-matter of claim 1.

4.7 Even if one assumed that the skilled person would have derived the idea of a dependency-defined server event cascade between (server-side) application components (corresponding to browser components) from D2 (see decision section 3.1.4 for the disclosure of dependencies and cascades in D2), then - in the framework of the invention - this would not only yield the intent of the observer pattern that a state change of a (server-side) object is notified to depending (server-side) objects (D2, page 293, first sentence), but also the surprising technical effect of a client-side browser component (BC2) receiving a response from its corresponding server-side object (application component AC2) without having sent a request for it. This reduces the network load between the client and the server computer. The board finds that this goes beyond an obvious combination of D1 and D2.

4.8 Therefore, claim 1 of the main request involves an inventive step, Article 56 EPC 1973.

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 with the order to grant a patent on the basis of claims 1-20 of the main request of the appealed decision, filed on 18 October 2012, with description and drawings to be adapted as necessary.

Quick Navigation