Author Archive

Generating a chip design using simulation: non-technical

This decision concerns the generation of a design model for a chip design using a simulation design tool. However, since the distinguishing features were considered non-technical in view of the most recent landmark decision G1/19 concerning computer-implemented inventions and simulations, the EPO refused grant. Here are the practical takeaways from the decision T 1768/20 (Characterization of standard cells/RACYICS) of July 3, 2023 of the Technical Board of Appeal 3.5.07.

Key takeaways

T 1227/05 (Circuit Simulation I/Infineon Technologies) is no longer relevant in view of the more recent landmark decision G 1/19.

A claimed manufacturing step could be an argument in favour of patentability of simulation-based inventions.

The invention

The subject-matter of the application is described in the Abstract of the originally filed specification as follows:

The invention discloses a method for an improved characterization of standard cells in a circuit design process. The object of the invention to provide a method for compiling library files, which are used for the design process of cells in digital circuits, whereas the adaptive body biasing (ABB) can be considered during the design process, will be solved by using simulation results of a cell set, which is defined by a fabrication process …

Fig. 1 of WO 2019/025030 A1

Claim 1 of the Main Request

Method for generating a design model with an improved characterization of a standard cell with adaptive body biasing in a circuit design process of said cells in digital circuits fabricated in a foundry, whereby the cell is defined by subject to variations due to the fabrication process P of said foundry, a supply voltage VDDnom and an operating temperature T, the method comprising the following steps:

– considering static deviations in the supply voltage VDDnom of the cell by a first pessimism +/- x%, resulting in VDDc,PVT = VDDnom +/- x%, and obtaining thereof a set of PVT corners with (Process, VDDc,PVT, Tc) for said PVT corners,

– defining a set of PVTBB corners indicating the PVT corner with body bias voltages for each PVT corner with (Process, VDDPVTBB, VPW, VNW, T) and

– providing the results of characterizing the cell with adaptive body biasing in a library file resulting in a design model for generating target VWN and VPN values for adaptive body biasing operation supported by a design implementation tool, characterized in, [sic] that the method is improved by

– simulating a cell set over P, V and T, and generating a data-set for a performance F of the cell set with F(VDD, T, VNW, VPW, Process(ss,tt,ff,sf,fs)) for a s-slow, t-typical and f-fast circuit property and VWN and VPW as body bias p-well and n-well voltages of the cell,

– simulating a performance monitor circuit for sensing a performance as a performance sensor over P, V and T, and generating a data-set for a hardware performance monitor value C from measurements with C(VDD, T VNW, VPW, Process(ss,tt,ff,sf,fs)) for a s-slow, t-typical and f-fast circuit property, further

– determining a reference performance F0 of a cell set at a particular PVT corner,

– determining a reference hardware performance monitor value C0 at the particular PVT corner,

– performing a virtual regulation and adapting of body bias voltages to VNWc0 and VPWc0 of the cell set such that said reference performance F0 of the cell set or said reference hardware performance monitor value C0 will be reached at each PVT corner of said set of PVT corners specified by (Process, VDDC0,PVTBB, (VPWc0, VNWc0) Tc0) and for compensating the static deviation in the supply voltage.

Is it patentable?

The application underlying the present decision was rejected by the first instance Examining Division due to lack of inventive step for the following reasons:

4.1 The examining division considered that, even assuming that storing results in a library file implied the use of technical means, the method of claim 1 of the current main request lacked an inventive step for the following reasons: first, it was well known to store cell characterisation data in library computer files (see document D1, columns 17 and 18). Second, the further steps corresponded to non-technical user requirements that, according to the COMVIK approach (see decision T 641/00), were part of the objective technical problem (see contested decision, point 2).

Against this finding, the appellant argued as follows in its statement of grounds of appeal:

4.2 In its statement of grounds of appeal, pages 4 to 8, the appellant submitted that the method of claim 1 was not a mental act as such but rather used a design tool as technical means. The claimed method generated a design model with improved characterisation of a standard cell. The results of said characterisation were stored in a library file containing library corners or so-called PVT corners. These data were used in the simulation process of standard cells for highly integrated semiconductor components by the customers and were needed to simulate how a designed circuit might work later (see description, page 3, starting at line 16).

To support this line of argumentation, the appellant inter alia referred to the famous circuit simulation decision (T 1227/05) and to the well-know nuclear reactor simulation decision (T 0914/02):

Referring to decision T 1227/05, the appellant argued that the method had a technical character as it concerned the technical field of chip manufacturing. Since the method was implemented by design tools, this added to the technical character in view of decision T 914/02. A direct use of controllable natural forces was not necessary for an invention (see statement of grounds of appeal, page 5, first and second full paragraphs).

However, the Board in charge did not follow these arguments and found that T 1227/05 is no longer relevant. Instead, the findings of G1/19 are now to be considered:

4.4 The board considers that the cited decision T 1227/05, which concerned computer-implemented methods for the numerical simulation of electronic circuits, is no longer relevant to the present case in view of the more recent decision G 1/19, which reconsidered the general approach for assessing the technical character of computer-implemented methods for simulation and design (see point 133). Consequently, decision G 1/19 is the essential case law that has to be considered when assessing inventive step in the current case, and the board summarises some relevant aspects of this decision below.

In the following, the Board in charge mainly relied on the following quotation of G1/19:

Point 128 of decision G 1/19 summarised that calculated data “reflecting the physical behaviour of a system modelled in a computer usually cannot establish the technical character of an invention in accordance with the COMVIK approach, even if the calculated behaviour adequately reflects the behaviour of a real system underlying the simulation. Only in exceptional cases could such calculated effects be considered implied technical effects (for example, if the potential use of such data is limited to technical purposes, see point E.I.f above)”. Point E.I.f comprises points 97 and 98.

The Board noted that claim 1 would fail to specify a further use of the claimed library file including the simulation results (i.e., the improved design model), e.g., in terms of a manufacturing step, which could be an argument in favour of patentability:

4.5 The board considers that, in the current case, the result of the calculations effected by the method steps of claim 1 is a design model with an “improved” characterisation that is obtained by simulation (see characterising part of claim 1, for example) of a standard cell which is provided in a library file. Such a library file is, at least according to the description, used by customers in later stages of the overall design process (see description of the published application, page 5, lines 12 to 17 and page 10, lines 3 to 11), but the method of claim 1 does not contain steps specifying the use of the produced library file in later design or manufacturing steps. A use of the design model in a manufacturing step would have been particularly relevant since the Enlarged Board of Appeal considered the inclusion of a manufacturing step to be an argument in favour of patentability (see point 134 of decision G 1/19).

Against this background, the Board concluded that the claimed improved design (stored in the library filed) fails to provide a technical effect. Hence, the corresponding features were ignored for the assessment of inventive step according to the COMVIK appraoch:

4.5.2 Since the result of the method of claim 1 is calculated data for an improved design that is obtained using simulation, it follows from points 97, 98 and 138 of decision G 1/19 that the improved design does not contribute to inventive step since no “further” technical effect, such as controlling a machine in the foundry during a manufacturing process, is derivable.

With regard to the two additional auxiliary requests, the Board did not come to a different assessment.

As a result, the appeal was dismissed.

More information

You can read the full decision here: T 1768/20 (Characterization of standard cells/RACYICS) of July 3, 2023

Stay in the loop

Never miss a beat by subscribing to the email newsletter. Please see our Privacy Policy.

Privacy policy * Yes, I consent to the collection, processing and use of my above-mentioned personal data for the purposes of processing my message and for the purposes of contacting me via email. The legal basis of the processing shall be formed by my consent pursuant to Art. 6 (1) lit. a GDPR. The data will be deleted three months after expiry of the purpose, provided that longer retention periods are not required by law. I can revoke this consent with future effect at any time. I have taken note of the privacy statement and consent to it. With regard to the processing of my data, I am entitled to inalienable rights, information on which can be found in the privacy statement.

* = Required field

Patrick Heckeler

Patrick is a European patent attorney at BARDEHLE PAGENBERG. He specializes in software patents in Europe both from a prosecution and litigation point of view.

www.bardehle.com/team/detail/heckeler-patrick.html

Transaction amount: non-technical

This decision concerns using NFC technology for conducting payments. However, since the distinguishing features were considered non-technical, the EPO refused grant. Here are the practical takeaways from the decision T 0801/20 (NFC mobile wallet processing system/PAYPAL) of June 1, 2023 of the Technical Board of Appeal 3.5.01.

Key takeaways

Data alone – whether technical or not – does not convey technical character to a method that processes it.

The invention

The Board in charge summarized the subject-matter of the application underlying the present decision as follows:

1.1 The invention concerns using near field communication (NFC) to make payments (page 1, third paragraph of the published application).

1.2 Looking at Figure 1, a user initiates a payment transaction by sending a transaction request from their NFC-enabled mobile device 102, such as a phone, to a transaction management system (TMS) 130. The TMS 130 then creates a pending transaction record and sends to the user’s device an NFC-formatted transaction identifier (“checkout token”). The user passes the token to a merchant system 108, e.g. by tapping their phone on an NFC reader 104 (page 45, lines 4 to 25).

The merchant system 108 then submits a merchant transaction request to the TMS 130, which includes the checkout token and some transaction details. The TMS updates the pending transaction record and sends the transaction details to the user along with a list of available payment accounts from which the user can select. Once the TMS receives the user’s selection, it completes the payment (page 45, line 22 to page 47, line 27).

1.3 An essential aspect of the claimed invention is that the merchant system transmits the transaction details to the TMS in two steps: the merchant’s identifier is sent with the transaction request, while the transaction amount is sent later. This is because the transaction amount might not have been calculated yet when the merchant’s transaction request is transmitted. The TMS also forwards the received pieces of transaction information to the user’s mobile device in separate steps (page 38, line 19 to page 39, line 19).

Fig. 1 of WO 2015/130967 A1

Claim 8 of the Main Request

A method executed by a transaction management system, TMS, comprising:

receiving, from a mobile device operated by a user, a request to initiate transaction processing associated with a transaction involving said user; and

transmitting, to said mobile device, a checkout token for use with said transaction, said checkout token formatted for near field communication (“NFC”) transmission from said mobile device to an NFC reader of a merchant system associated with said transaction;

creating a pending transaction record associated with the checkout token, which includes information identifying the user, in a transaction queue;

receiving, from said merchant system, a message containing (i) the checkout token received from the mobile device via an NFC communication session between the mobile device and the NFC reader, and (ii) details of a transaction involving said merchant and said user including a merchant identifier but not a transaction amount;

updating the pending transaction record with the details of the transaction by matching the message from the merchant and the pending transaction record using the checkout token;

transmitting payment accounts and information identifying the merchant for display by the mobile device;

receiving a transaction amount from said merchant system;

updating the pending transaction record using the transaction amount;

transmitting a message to the mobile device so that the display of the mobile device is updated to include the transaction amount as well as a list of available payment accounts that can be used in the transaction and information identifying the merchant;

receiving, from said mobile device, a transaction confirmation request message including a user selection of one of the available payment accounts; and

identifying, based on information from said transaction confirmation request message, an actual payment account corresponding to said user selection for use in completing said transaction.

Is it patentable?

The application underlying the present decision was rejected by the first instance Examining Division due to lack of inventive step (cf. decision, “Summary of Facts and Submissions”). With the aim to set this decision aside, the applicant lodged an appeal. At appeal stage, as a first step, the Board in charge determined the distinguishing features of claim 8 over the closest prior art document D1 as follows:

(i) The merchant system transmits the transaction details to the TMS in two steps: first, it sends the merchant’s identifier, and then the transaction amount. After each step, the TMS updates the pending transaction record and forwards the received information to the user.

(ii) The TMS sends a list of “available” payment accounts from which the user can select to complete the payment.

According to the appellant’s arguments, specifically the claimed “amount” according to distinguishing feature (i) would be of technical nature as it would refer to a quantity:

2.3 As regards feature (i), the appellant argued that an “amount” was technical as it represented a quantity. It was inconsistent to say that an amount was technical when it referred to a physical parameter, such as voltage, but non-technical when it referred to money. Furthermore, transmitting and receiving data to/from a device, as well as updating a data record, were all technical processes.

However, the Board in charge disagreed and considered to claimed “amount” non-technical and reasoned its finding as follows:

2.4 The Board notes that an amount is just a number and per se non-technical. Whether this number represents technical or non-technical data depends on the context. However, data alone – whether technical or not – does not convey technical character to the method that processes it. Method steps contribute to the technical character of the invention only if they contribute to the solution of a technical problem by providing a technical effect (e.g. T 154/04 – Estimating sales activity/DUNS LICENSING, point 20).

Furthermore, the appellant considered the two-step approach reflected in distinguishing feature (i) to be technical and argued as follows:

2.5 The appellant further argued that the two-step transmission and display of transaction details enabled the user to verify the merchant’s identity while waiting for the transaction amount to be determined. Receiving transaction information piece by piece was easier for the user to process, saved time and reduced latency.

Again, the Board did not follow the appellant’s arguments:

2.6 The Board does not find this argument convincing. Displaying information piece by piece or all at once is a matter of user preference. Some users may prefer to receive the merchant details in advance, others may prefer to see all relevant information together. Even if a user receives the merchant’s identity beforehand, they may still choose to wait until all transaction details arrive before reviewing them. Thus, any effect the displayed information might have depends on the user and the user’s reaction to this information. Such indirect effects cannot be considered when assessing inventive step (see e.g. T 1670/07 – Shopping with mobile device/NOKIA, point 11). Although displaying information piece by piece may make it easier to evaluate and, hence, lower the user’s cognitive burden, this is not a technical effect (see e.g. T 1741/08 – GUI layout/SAP, point 2.1.6).

With respect to distinguishing feature (ii), the appellant was of the opinion that this feature would lead to a bandwidth reduction:

2.7 As regards feature (ii), the appellant argued that by providing a list of accounts that were suitable for the transaction, the system required less bandwidth and computing resources. This was because, on the one hand, non-usable accounts were not transmitted, and, on the other hand, the system did not have to process non-viable account selections.

However, the Board noted that the payment accounts are even transmitted twice and thus doubts that this may result in improved transmission efficiency:

2.8 The Board is not convinced that the effects identified by the appellant are achieved. According to the claim, the TMS transmits payment accounts to the user’s mobile device twice: first, it transmits some unspecified payment accounts, and then, it transmits “a list of available payment accounts that can be used in the transaction”. …

Against this background, the Board concluded that both features (i) and (ii) are non-technical and thus have to be ignored for the assessment of inventive step. Hence, D1 would render obvious the claimed subject-matter of claim 8 of the Main Request.

Since claim 7 of the Auxiliary Request was also considered non-inventive, the Board in charge dismissed the appeal.

More information

You can read the full decision here: T 0801/20 (NFC mobile wallet processing system/PAYPAL) of June 1, 2023

Stay in the loop

Never miss a beat by subscribing to the email newsletter. Please see our Privacy Policy.

* = Required field

Patrick Heckeler

Patrick is a European patent attorney at BARDEHLE PAGENBERG. He specializes in software patents in Europe both from a prosecution and litigation point of view.

www.bardehle.com/team/detail/heckeler-patrick.html

Reminders on a mobile device: non-technical

This decision concerns a mobile phone application allowing event configuration and processing. Specifically, a user may specify that an image is to be displayed at a certain time and the system monitoring the time and displaying the image at the specified time. However, most of the claimed features were considered non-technical and since the technical distinguishing features were considered obvious, the EPO refused grant. Here are the practical takeaways from the decision T 1682/20 (Image reminder system/LG) of March 10, 2023 of the Technical Board of Appeal 3.5.06.

Key takeaways

Non-technical user requirements cannot contribute to inventive step.

The invention

The Board in charge summarized the subject-matter of the application underlying the present decision as follows:

1. The application relates to a mobile terminal configured to classify, manage, and display images. In particular, the mobile is configured to associate images to events, and to display the images upon detection of the associated event (paragraph 3). The event may be location, time, or application related (paragraph 5). The user can configure the event by voice input (paragraphs 61, 164, 189). For instance, the user can take an image of a specific parking spot, and this image can be displayed upon the user returning to the parking area (paragraph 49); or the user may desire that an image is displayed on a certain date (e.g. a birthday; see paragraphs 49, 167); or when an application is opened (e.g. a banking app; see paragraphs 190 – 191). The annotated images may be automatically deleted after a certain amount of time (paragraph 146).

Fig. 1 of EP 3 139 304 A1

Claim 1 of the Main Request

A mobile terminal (100) comprising:

a storage unit (170);

an input unit (120);

a display unit (151); and

a control unit (180) is configured to:

receive a voice input to input event information relating to an image through the input unit (120), while the image is displayed;

store, in the storage unit (170), the event information relating to the image;

detect an event;

determine that the detected event corresponds to the event information;

display, on the display (151), the image related to the event information, if the detected event corresponds to the event information,

wherein the control unit (180) is configured to:receive the voice input to input event information relating to the image, wherein the event information relating to the image includes information on a time point at which the image is to be displayed again,obtain information on the time point using the voice input and information pre-stored in the mobile terminal (100) and store the obtained information on a time point;

wherein the control unit (180) is configured to display the image if an event arriving at the stored time point is detected.

Is it patentable?

The first instance examining division identified several distinguishing features over the closest prior art document D1:

3. The Examining Division started its analysis from D1 and acknowledged a set of differences (see the decision, point 13.4) related to the event configuration and processing, essentially about the user specifying that an image is to be displayed at a certain time and the system monitoring the time and displaying the image at the specified time.

Since the distinguishing features were considered non-technical, the examining division used some of them in the formulation of the objective technical problem:

3.1 It argued in essence (decision 13.5 to 13.11), with reference to the description at paragraphs 49-52, 199 and 275, that the effect of these differences over D1, namely the users’ “satisfaction” or their “being reminded of past events” occurred only in the head of the user and hence was not a technical effect. Moreover, scheduling as such was an administrative consideration. The relevant steps could thus be used as a constraint in the formulation of the objective technical problem according to the problem-solution approach.

3.2 The objective technical problem given to the skilled person was therefore how to implement, on the mobile terminal of D1, the requirements specification that encompasses the distinguishing procedural steps. The technical implementation of these steps was a matter of routine computer programming and did not involve an inventive step.

Since the implementation of the aforementioned steps was considered a routine task, the examining division rejected the application due to lack of inventive step.

In the grounds of appeal, the Appellant argued that the examining division did not properly define the technical problem and suggested the following problem formulation:

4.1 … The objective technical problem, based on the differences identified, should therefore be formulated as follows: “how to provide an efficient means for configuring inputs to a form of reminder system on a mobile terminal”.

According to the Appellant, D1 does not suggest a solution to this problem.

In its assessment, the Board in charge considered both D1 and a standard mobile device with photo capabilities and voice input as suitable starting points to arrive at the claimed subject-matter (cf. decision, item 5). Over each of the two possible starting points, the invention would provide the following addition:

6. The claimed subject matter can be summarized, as also stated by the Appellant, as providing a form of reminder system on a mobile device. This system displays images upon activation of the reminder; the user configures the reminder by using voice input.

However, the Board considered this as pure non-technical user requirements:

6.2 Reminders, in general, are meant to bring a piece of information to the users’ attention when they want it. The type of information that users want to be reminded of and the (type of) conditions triggering the reminder are therefore user requirements.

The only technical contribution was identified as follows:

6.6 The only difference features that do not follow immediately from the user requirements are those related to the (sub-)problem identified by the appellant, i.e. how to enable user input for configuring the reminder.

Then, the Board found that considering user input at a mobile device was a standard routine for the skilled person:

6.7 In the Board’s view, the skilled person would consider user input in any conventional modality available on a mobile device. This includes voice, as exemplified by D1 in paragraph 32.

Hence, the Board arrived at the conclusion that the claimed subject-matter would be rendered-obvious when starting from D1. The same would apply if one would consider a standard mobile phone as starting point (cf. decision, item 7).

Finally, the Board expressed that similar considerations would apply to the auxiliary requests.

Consequently, the Board in charge dismissed the appeal due to lack of inventive step.

More information

You can read the full decision here: T 1682/20 (Image reminder system/LG) of March 10, 2023 of March 10, 2023.

Stay in the loop

Never miss a beat by subscribing to the email newsletter. Please see our Privacy Policy.

* = Required field

Patrick Heckeler

Patrick is a European patent attorney at BARDEHLE PAGENBERG. He specializes in software patents in Europe both from a prosecution and litigation point of view.

www.bardehle.com/team/detail/heckeler-patrick.html

Accepting a transaction if information about it provided by a customer and a POS coincide within certain limits: non-technical

This decision concerns an application relating to the authentication of a wireless payment transaction at a point of sale (POS). However, since the distinguishing features were considered to refer to a business scheme, the EPO refused grant. Here are the practical takeaways from the decision T 0768/17 (Authenticating wireless payments/VODAFONE) of January 26, 2023 of the Technical Board of Appeal 3.5.01.

Key takeaways

Business ideas do not involve any technical considerations.

The invention

The Board in charge summarized the subject-matter of the application underlying the present decision as follows:

3.1 The invention concerns the authentication of a wireless payment transaction at a point of sale (POS) (see published application, paragraphs [6] and [7]).

3.2 Looking at Figure 3, the core idea is to receive independently information about a payment transaction from the POS’s reader device (120 – “first information about the transaction” in the claims) and a customer’s mobile communication device (110 – “second information about the transaction”) and to accept the transaction only if those information items “coincide within certain limits”, see [12] and [16]. This effectively means that the transaction is rejected if the mobile device and the POS terminal provide inconsistent information about it.

3.3 Payments are conducted using a payment identifier which the mobile communication device receives from a backend system (105). While not claimed, but disclosed in the application, the identifier may be for example an IBAN, see [5] and [38].

In order to carry out a payment at the POS, the mobile communication device wirelessly transfers the identifier, stored in a secure element (115), to the reader device ([6]) along with the first information about the transaction ([12] and [13]). The reader device forwards the received data to the backend system, which is entrusted with the transaction authentication, via a first communication channel. Additionally, the mobile device prepares the second information about the transaction and sends it to the backend system via a second wireless communication channel, see [12], [16], [25] and [28].

The backend system compares the first and second information and if they coincide within certain limits ([16]), it instructs a bank system to effect the payment ([40]).

Fig. 3 of EP 2 824 628 A1

Claim 1 of the fifth Auxiliary Request

A system comprising a mobile communication device (110) and a backend system (105), wherein the mobile communication device (110) comprises

a radio interface (112) for receiving at least a part of an identifier provided by means of a backend system (105);

a secure element (115) being adapted to store the transmitted identifier;

a processor for preparing a transaction to a reader device (120) by means of at least a part of the transmitted identifier and first information about the transaction;

a transaction interface (116) for transferring at least the part of the transmitted identifier and the first information about the transaction to a reader device (120) for starting the transaction; and

wherein the processor is adapted to prepare second information about the transaction and the radio interface (112) is adapted to transmit the second information about the transaction to the backend system (105) after starting the transaction;

and wherein the backend system (105) comprises a backend processor (102) for generating the identifier, the backend system further comprises a backend memory (101) for storing the identifier and a backend interface (103) for transmitting at least a part of the identifier to the mobile communication device (110);

the backend interface (103) being further adapted to receive via a first communication channel a request of confirmation comprising at least the part of the identifier transferred to the reader device (120) and first information about the transaction;

the backend interface (103) being further adapted to receive the second information about the transaction from the mobile communication device (110) via a different second wireless communication channel;

the backend processor (102) being adapted to compare the first and second information about the transaction;

the backend processor (102) being further adapted to authenticate the request and to prepare a confirmation to verify the identifier transferred to the reader device (120) if the comparison reveals that the first and the second information coincide within certain limits, and

the backend interface (103) being further adapted to transfer the confirmation for initiating a payment by means of a bank system (130), if the request is authenticated.

Is it patentable?

The Board started its assessment with the fifth auxiliary request as this request is the most specific one.

At first, the Board determined the distinguishing features of claim 1 in view of the closest prior art document D1 as follows:

A) The backend interface (103) is further adapted to receive via a first communication channel a request of confirmation comprising at least the part of the identifier transferred to the reader device (120) and first information about the transaction;

B) The backend interface (103) is further adapted to receive the second information about the transaction from the mobile communication device (110) via a different second communication channel;

C) The backend processor (102) is adapted to compare the first and second information about the transaction;

D) The backend processor (102) is further adapted to authenticate the request and to prepare a confirmation to verify the identifier transferred to the reader device (120) if the comparison reveals that the first and second information coincide within certain limits;

E) The backend interface (103) is further adapted to transfer the confirmation for initiating a payment by means of a bank system, if the request is authenticated (130).

With respect to feature C), the appellant argued that this feature would be based on technical considerations. This is because it would allow to detect human mistakes, fraudulent data manipulation and transmission disturbances (cf. decision, Section XV, 1st para.).

Hence, the technical problem could allegedly be formulated as follows:

The technical problem was to enable data exchange between the relevant devices such that the manipulation of electronically processed transaction data could be detected.

Verifying transactions by comparing the first and second information was quite similar to using checksums which was technical. The condition that the first and second information coincided within certain limits, rather than being identical, reflected the fact that the technical system in the real world incurred some error which should be allowed for.

To substantiate his position, the appellant argued that verifying transactions by comparing the first and second information was quite similar to using checksums which was technical (cf. decision, Section XV, 3rd para.).

However, according to the Board, the distinguishing features would only refer to a business method and, consequently, considered them as being non-technical:

4.4 As set out above, the distinguishing features implement the idea that the transaction is accepted if the information about it provided by the customer and the POS coincide within certain limits. Like the contested decision and contrary to the appellant’s view (see decision, pages 5 to 6 and section XV above), the Board judges that this is a business idea which does not involve any technical considerations. Entrusting the backend instance with authenticating transactions is a further business decision.

Moreover, the Board could not see that the alleged technical effect (see above) is actually achieved by the distinguishing features over the whole scope as claimed:

4.6 Contrary to the appellant’s view, the Board cannot see that, at the level at which they are defined, the distinguishing features enable detecting transmission disturbances between the user mobile device and the reader device.

…

4.7 Furthermore, in view of the lack of detail concerning the content of the compared information and the vagueness of the comparison criterion, the Board doubts that the alleged effect of detecting a human mistake or fraudulent manipulation of transaction data is achieved over the whole scope of the claim.

Even if one would assume that the claimed method would allow the detection of human mistake and manipulation, these effects would stem from a business idea and could thus not contribute to inventive step:

However, even assuming that in some cases a human mistake and manipulation could be detected, these effects would result from the aforementioned business idea and not from its technical implementation and, therefore, would not count towards an inventive step.

Against this background, in line with the COMVIK principles, the Board concluded that claim 1 of the fifth auxiliary requests lacks inventive step. Since claim 1 of the first to fourth auxiliary requests are broader than claim 1 of the fifth auxiliary request, they would lack an inventive step for the above reasons, too.

Consequently, the Board in charge dismissed the appeal.

More information

You can read the full decision here: T 0768/17 (Authenticating wireless payments/VODAFONE) of January 26, 2023.

Stay in the loop

Never miss a beat by subscribing to the email newsletter. Please see our Privacy Policy.

* = Required field

Patrick Heckeler

Patrick is a European patent attorney at BARDEHLE PAGENBERG. He specializes in software patents in Europe both from a prosecution and litigation point of view.

www.bardehle.com/team/detail/heckeler-patrick.html

Identifying an overall suspicion level for a transaction: non-technical

This decision concerns an application relating to a video-based method and system for detecting whether goods or items have been properly scanned at point-of-sale or cashier terminals. However, since the distinguishing feature was considered to refer to a subjective perception, the EPO refused grant. Here are the practical takeaways from the decision T 2156/17 (Detecting suspicious activity using video analysis / NCR Corporation) of June 10, 2022 of the Technical Board of Appeal 3.4.01.

Key takeaways

Terms that merely concern a subjective perception (like a “suspicion level”) can typically not contribute to the technical character.

The invention

The invention underlying the present decision may be summarized as follows:

Conventional cashier or point-of-sale (POS) systems that provide for purchase of items using a scanner or other automated identification of items via code suffer from a variety of deficiencies. In particular, operation of such systems can be compromised either knowingly or unknowingly by an operator in a manner that allows a customer to receive possession of one or more items without paying for them. In particular, such systems are susceptible to “pass-throughs”, also know as “sweethearting” in which an operator purposefully or accidentally fails to scan an item as that item moves through the transaction area. In such cases, the POS system never detects the unscanned item and the item is thus never totaled into the purchase price. In such cases, the customer effectively receives the item for free. Retail chains lose millions of dollars a year to operator error or fraudulent activity of this nature. In a non-fraudulent example, an operator may unknowingly pass an item through the scanning area during a transaction and place the item into the item output area such as a downstream conveyor belt, but no scan of the item took place. Perhaps the operator was not paying attention and did not notice (or did not care) that the scanner failed to beep during scanning of an item (cf. WO 2006/105376 A2, p. 2, l. 9-25).

The system according to the invention uses video data analysis techniques as will be explained to detect activity such as sweethearting or pass-throughs. In particular, the system detects incidents of theft or loss of inventory at the cash register, POS or other transaction terminal when an operator such as a customer or store employee passes one or more items around the scanner (or RFID reader) without being scanned, or when the operator scans or manually enters an incorrect code into the transaction terminal for an item. The system can also detect items which may be mislabeled with an incorrect bar code to be misread by the scanner or entered as the wrong item by the operator (cf. WO 2006/105376 A2, p. 3, l. 30-37).

Fig. 1 of WO 2006/105376 A2

Claim 1 of the first Auxiliary Request

A computer-implemented method for detecting a transaction outcome, the method comprising:

obtaining video data associated with a transaction area;

analyzing at least a portion of the video data to obtain at least one video parameter concerning at least a portion of a transaction associated with the transaction area, wherein the step of analyzing comprises automatically analyzing frames of video from at least one region of interest in the at least a portion of the video data to identify a respective event indicating the presence of an item associated with the transaction;

obtaining at least one transaction parameter originated from a transaction terminal associated with the transaction area, wherein the step of obtaining comprises analyzing at least a portion of transaction data from a transaction terminal to identify a sequence of items identified as being transacted in the transaction; and

automatically comparing the at least one video parameter to the at least one transaction parameter to identify a transaction outcome, wherein the step of automatically comparing comprises analyzing the sequence of items identified as being transacted in the transaction from the transaction data in comparison to the events produced from analysis of the video data to determine if the item represented by at least one event produced from the analysis of the video data is indicated as an item for transacting in the at least a portion of transaction data, and correlating video timestamps of events from the analysis of the video data to transaction timestamps of items reflected as having been transacted in the transaction data to identify events indicating an item in the video data that does not have a corresponding record in the transaction data,

obtaining video data further comprising:

obtaining video data originating from at least one elevated video camera that monitors a transaction area defining the region of interest; and

wherein analyzing at least a portion of the video data comprises:

analyzing the video data to track items involved in the transaction in the transaction area; and

wherein automatically comparing the at least one video parameter to the at least one transaction parameter to identify a transaction outcome comprises:

comparing the video analysis of the tracked items to transaction data produced from a transaction terminal to identify suspicious activity,

producing a set of detection events indicating detection of items by at least one detector within at least one region of interest of at least one portion of the video data;

wherein automatically comparing the at least one video parameter to the at least one transaction parameter comprises:

for each detector, comparing the set of detection events for that detector to at least a portion of transaction data taken at the time of the event to identify at least one apparent discrepancy in a number of items detected by that detector from a number of items indicated in the at least a portion of the transaction data; and

identifying an overall suspicion level for the transaction based on apparent discrepancies identified by the at least one detector.

Is it patentable?

First of all, the Board in charge rejected the Main Request because of a lack of inventive step (cf. Reasons for the Decision, items 1-30). Then the Board turned to the first Auxiliary Request and determined the distinguishing features over the closest prior art document D6 as follows:

33. The claimed method is further distinguished from the method of D6 in that the process is automatic, in that it incorporates a step of comparing the set of transaction events with the transaction data in order to identify a discrepancy in the respective number of items, and in the further step of identifying an overall “suspicion level” for the transaction.

However, according to the Board, specifically the comparison step to identify a discrepancy to generate a suspicion level would lack technical character:

34. Contrary to the appellant’s view, the step of comparing the set of detection events with the set of transaction data to identify a discrepancy is not technical. Independently of the nature of the events, it must be stressed that the comparison carried out simply compares data. All in all, the claimed step of comparing said data amounts to a mere comparison of lists by computer means.

35. The origin of the data are without bearing on the claimed step of comparing. The technicality of the transaction, as it manifests itself in the movement of items in a sequence of video frames, is lost when it comes to the step of comparing the data. The Board further rejects the view that the count that results from the comparison is technical in the context of the invention. The mere fact that the identification of a discrepancy is used to generate a “suspicion level” is also not sufficient to confer technical character to said method. The notion of “suspicion” is essentially subjective and as such not technical. The same applies to any parameters that may be derived therefrom.

Against this background, the Board concluded that the only feature of technical nature that distinguishes the claimed method from the teaching of D6 resides in the automation of the claimed process (cf. decision, item 36). However, since this would simply reflect a trend in technology, this feature would not be sufficient for an inventive step.

Since all other requests would either be inadmissible or would lack inventive step, the Board in charge dismissed the appeal.

More information

You can read the full decision here: T 2156/17 (Detecting suspicious activity using video analysis / NCR Corporation) of June 10, 2022.

Stay in the loop

Never miss a beat by subscribing to the email newsletter. Please see our Privacy Policy.

* = Required field

Patrick Heckeler

Patrick is a European patent attorney at BARDEHLE PAGENBERG. He specializes in software patents in Europe both from a prosecution and litigation point of view.

www.bardehle.com/team/detail/heckeler-patrick.html

Labelling a package with cross-referenced information and using this information for retrieval: technical

This decision concerns an application relating to tracking of packaged products, such as milk. However, despite the technical contribution of one of the distinguishing features, the EPO refused grant since the claimed subject-matter would be rendered obvious by the cited prior art. Here are the practical takeaways from the decision T 2771/18 (Content tracking/TETRA LAVAL) of January 11, 2023 of the Technical Board of Appeal 3.5.01.

Key takeaways

While the meanwhile abandoned “contribution approach” led to the conclusion that the entirety of a claimed subject-matter is excluded from patentability under Article 52(3) EPC, the currently applicable COMVIK approach determines the technical contribution of individual features (by taking into account the complete claim), which may the be considered or not for the assessment of inventive step. Hence, the COMVIK approach can only lead to rejections under Art. 56 EPC.

The invention

The Board in charge summarized the invention underlying the present decision as follows:

1.1 The invention concerns the tracking of packaged products, such as milk (published application, first paragraph).

1.2 The claimed method comprises steps of obtaining various pieces of information about a product, such as information about the raw material and the packaging, storing this information in an electronic database together with corresponding time stamps, “cross referring” the information, and labelling a packaged product with the cross-referenced information. Finally, based on the labelling information, stored information about the product is retrieved and used to recall the packaged product (page 5, line 3 to page 6, line 34).

This information about the origin and processing of a product enables, for example, packages containing milk from a contaminated farm to be identified and discarded (e.g. page 9, lines 3 to 10).

Fig. 3 of WO 2011/010958 A1

System Claim 1 of Main Request

A method for content tracking of a packaged content in a package comprising the steps of

obtaining information of the raw material;

obtaining transport information;

obtaining process information;

obtaining packaging information;

storing said information of raw material, transport information, process information and packaging information in an electronic database;

wherein each piece of information of said information is stored together with a time stamp stating when respective piece of information is generated;

cross referring, by a computer, said stored information based on said time stamp for each of said information pieces and that said pieces of information are generated in a pre-determined sequence;

generating, by a computer, an output comprising said cross referenced information; and

labelling the package with said output;

such that said content can be tracked along a timeline and accurately generating an output comprising said cross referenced information for each package

retrieving the stored information based on the labelling information from the package, and

perform a surgical recall of the packages based on the retrieved stored information.

Is it patentable?

During the appeal stage, the Appellant argued that the first instance examining division would have incorrectly the COMVIK approach (T 641/00). This is because the examining division would have indicated which features of claim 1 of the main request were non-technical before identifying the closest prior art. This process would be known as the “contribution approach” which, however, has been abandoned:

2.2 The appellant argued that the examining division did not correctly apply the COMVIK approach (T 641/00). This approach required identifying the closest prior art and the distinguishing features over this prior art before assessing the technical and inventive step contribution of these features. In contrast, the examining division indicated which features of claim 1 were non-technical before identifying the closest prior art. In the appellant’s opinion, the approach taken by the examining division was similar to the abandoned “contribution approach” (e.g. the Case Law Book, 10th edition, I.D.9.2.1).

However, the Board in charge did not agree to the Appellant’s arguments:

2.3 The Board cannot see how the examining division failed to follow the COMVIK approach. At point 3.1 of the decision, the division identified a computer and an electronic database as the only technical features of claim 1. The rest of the claim was said to define a business/administrative method. This led the examining division to choose a general-purpose networked data processing system as the closest prior art (point 3.2). The Board considers that it is legitimate to select the closest prior art based on the technical features of the claim (e.g. T 0172/03 – Order management/RICOH, points 11 to 18). This approach is also outlined in the Guidelines for Examination, section G-VII, 5.4.

After choosing the closest prior art, the examining division identified the distinguishing features as the steps of the business scheme listed previously under point 3.1 (see point 3.3). The division then formulated the objective technical problem as how to implement this business scheme in the known computer system (point 3.4). Finally, the division argued that the solution in claim 1 was obvious and concluded that the claim lacked an inventive step (point 3.5).

As a result, the Board arrived at the conclusion that the examining division correctly applied the COMVIK approach since the examining division determined that the distinguishing features did not contribute to the technical character of the claimed subject-matter. This would be something different than denying the technical character of an invention as a whole, as done in the past according to the “contribution approach”:

2.4 Hence, the examining division followed a generally established approach for assessing the inventive step of inventions comprising mixtures of technical and non-technical features. The division acknowledged that claim 1 comprised technical means and, therefore, had technical character as a whole. The division, however, concluded that the claim lacked an inventive step since the distinguishing features did not contribute to this technical character. This is different from the “contribution approach” mentioned by the appellant, where the lack of technical contribution over the prior art leads to the conclusion that the entirety of the claimed subject-matter is excluded from patentability under Article 52(3) EPC.

Since the Appellant was of the opinion that prior art document D2 would form a more promising starting point to arrive at the claimed subject-matter, the Board in charge, for the sake of completeness, exercised the COMVIK approach based on D2 as closest prior art document and identified the following distinguishing features:

2.8 … Hence, D2 stores and retrieves information in the same way as the claimed invention … D2, however, does not disclose labelling a package with cross-referenced information and using this information for the retrieval ….

The Board considered this feature technical and thus formulated the objective technical problem to be solved as follows:

2.9 The Board agrees with the appellant that labelling a package is technical, as it relates to a physical activity. A label comprising cross-referenced information enables retrieving information about the packaged content. Hence, the problem solved can be formulated as how to obtain information about packaged content from the database of D2.

However, the combination with prior art document D1 would render obvious the claimed subject-matter:

2.10 It is standard practice to label a package with information about its content (see e.g. D1, [0008]). In view of this, and when faced with the problem above, the skilled person would have chosen to label the package with a piece of information that can be used to retrieve further information about the packaged content. As the content’s identifier of D2 (i.e. the WorkID, [0044]) fulfils this requirement ([0053] to [0056]), it would have been an obvious choice. Since the further information (e.g. information about processing and transport events) is cross-referenced to the WorkID, the skilled person would have arrived at the subject-matter of claim 1 in an obvious way.

To counter the assessment of the Board, the Appellant argued that the invention would provide further technical effects:

2.12 According to the appellant, the cross-referencing ensured that “the entire process meets the necessary standards with respect to the sequence of the process and is performed within the required time period”. The process thus ensured that a package “meets the requirements of safety prior to labelling”.

2.13 The appellant also argued that the invention helped avoid counterfeit products since a fake label could be easily identified when querying the database with the information on the label.

2.14 Finally, the appellant argued that the method allowed for retrospective and accurate recall of contaminated packages.

Concerning the argument according to item 2.12, the Board doubted that this effect is technical. Moreover, this feature would be known from D2.

With respect to the argument of item 2.13, the Board argued that this consideration would extend beyond the scope of the claim and the application as a whole.

Finally, with respect to item 2.14, the Board found that the feature in question would only relate to a non-technical activity.

As a result, the Board dismissed the appeal since the claimed subject-matter would lack inventive step.

More information

You can read the full decision here: T 2771/18 (Content tracking/TETRA LAVAL) of January 11, 2023.

Stay in the loop

Never miss a beat by subscribing to the email newsletter. Please see our Privacy Policy.

* = Required field

Patrick Heckeler

Patrick is a European patent attorney at BARDEHLE PAGENBERG. He specializes in software patents in Europe both from a prosecution and litigation point of view.

www.bardehle.com/team/detail/heckeler-patrick.html

Insurance-risk prediction: non-technical

This decision concerns an application relating to insurance-risk prediction. However, the EPO refused the application as an obvious implementation of a non-technical scheme. Here are the practical takeaways from the decision T 2626/18 (Insurance risk prediction/SWISS RE) of September 28, 2022, of the Technical Board of Appeal 3.5.01.

Key takeaways

A comparison with the prior art, for example with what humans did before an invention, is not a suitable basis for establishing technical character of subject-matter excluded from patentability.

The invention

The Board in charge summarized the invention underlying the present decision as follows:

2.1 The invention concerns insurance-risk prediction and provides a model analysing potential losses of a company to be insured in order to determine the price of the company’s insurance policy (originally filed application, page 2, line 6 to page 4, line 15).

The model analyses a hypothetical scenario, in which an event causes a loss to the company (page 18, line 1 to page 19, line 9). While not explicitly disclosed, but argued by the appellant during oral proceedings, such an event could be, for example, an accident on the company’s premises. Looking at the Table on page 35 of the original application, the model contains interconnected components called liability risk drivers or LRD members. For example, there is a liability risk driver predicting possible property damage and human injuries resulting from human error (page 44). Another liability risk driver predicts the amount awarded by courts to injured persons as a result of mass litigation (page 35, line 19, to page 36, line 25). The model combines the output of the liability risk drivers and calculates the expected loss cost (page 51, line 26 to page 52, line 8). As shown in the third column of the aforementioned Table, the liability risk drivers employed by the main embodiment analyse business and legal factors only.

3. The claimed invention

The claimed invention additionally assigns to the liability risk drivers physical parameters acquired by measuring devices. The application is not specific as to what sort of physical parameters are used; it discloses merely that the measuring devices “can comprise…all kind of sensors and data capturing or data filtering devices” (page 14, lines 9 to 11). The application does not disclose any embodiment in which particular sensor measurements are processed.

Furthermore, the claimed invention comprises a loss resolving unit that resolves an unspecific loss occurring at a so-called loss unit.

The claims do not provide any technical details of the computer implementation. The application merely states that the claimed units can be implemented in software (page 15, lines 20 to 22).

Fig. 1 of EP 2 461 286 A1

System Claim 1 of Auxiliary Request I

A forecasting and signaling system for automated and automatically tuned operation of a loss resolving unit (40) by means of a control unit controller (10) by forecasting loss frequencies and severities based on captured measure parameters of measuring devices (201,…,261), interacting electronically by signal generation modules and appropriate signal generation, whereas the signal generation is based on forecasted frequencies associated to future loss and loss distributions for individual risks of a plurality of operating units (30) by means of the control unit controller (10), the operating units being exposed to said risk measurable by physical parameters for causing a loss at a loss unit (20,…,26), whereas in case of an occurring loss at a loss unit (20,…,26) the system comprises measuring devices (201,…,261) to scan for, measure and transmit measure parameters to the control unit controller (10), and whereas the control unit controller (10) comprises means to operate the automated loss resolving unit (40) resolving the occurred loss, the loss resolving unit (40) comprising dedicated repair nodes comprising automatic or semiautomatic systems to maintain operation or recover loss of the loss units (2) in case of the occurring loss, characterized

in that the control unit controller (10) comprises a trigger module to dynamically scan, monitor and capture for measuring devices (201,…,261) assigned to the loss units (20,…,26) for measure parameters and to select measurable measure parameters capturing a process dynamic and/or static characteristic of at least one liability risk driver (311-313) by means of the control unit controller (10), each liability risk driver (311-313) representing a measurable real-world liability exposure (31) of an operating unit (30), wherein measuring possibilities at the measuring devices (201,…,261) are dynamically captured and the at least one liability risk driver (311313) is generated based on the on the captured measuring devices (201,…,261) and assigned to the currently measured parameters, and wherein the measuring parameters associated with the generated liability risk drivers (311-313) are measured and transmitted to the control unit controller(10),

in that the control unit controller (10) comprises a driver selector (15) to select a set (16) of liability risk drivers (311-313) parameterizing the liability exposure (31) of the operating unit (30) and dynamically assign the measured measure parameters to the liability risk drivers (311-313), whereas a liability exposure signal of the operating unit (30) is generated based upon measuring the selected measure parameters by means of the measuring devices (201,…,261),

in that the driver selector (15) comprises means to dynamically adapt the set (16) of liability risk drivers (311-313) varying the liability risk drivers (311-313) in relation to the measured liability exposure signal by periodic time response, and adjust the liability risk driven interaction between the loss resolving unit (40) and the operating unit (30) based upon the adapted liability exposure signal,

in that the control unit controller (10) comprises a scenario generator (131) for generating loss scenarios, wherein loss scenarios are given by variables of the control unit controller (10) connecting the liability risk drivers (311-313) to form a function structure, wherein for each scenario a loss model is generated with a frequency distribution function assigned and wherein an expected loss in generated by an aggregator (135) based on a model input and a generated frequency of losses out of the frequency of events and a distribution of a number of losses per event, and

in that a structure of the currently used liability risk divers (311-313) is adapted by the control unit controller (10) by generating and assigning the appropriate liability risk drivers (311-313) based on the currently scanned measure parameters, wherein the liability risk driver structure is based on the generated scenarios, and wherein a specific risk is decomposed by the scenarios into system components of the control unit controller (10), on which the risk drivers (311-313) act independently.

Is it patentable?

In accordance with the first instance examining division, the Board considered that an appropriate starting point to arrive at the claimed invention (according to Auxiliary Request I) is a computer system connected to sensors (rather than just a computer). Then, the Board defined the distinguishing features as follows:

4.5 The claim differs from this starting point by the control unit controller, its sub-units, the loss units and the loss resolving unit.

Afterwards, the Board commented on the main point in dispute, i.e. whether the distinguishing features contribute to the solution of a technical problem, as follows:

4.6 The main point of dispute in this appeal is whether these distinguishing features define a technical solution, as argued by the appellant (see section XI., above), or non-technical matter that could be envisaged by the business person and thus be part of the requirement specification given to the technically skilled person, as considered by the examining division.

4.7 Based on the above understanding of the claimed invention, the Board concludes that the distinguishing features relate per se to an abstract insurance model for predicting future losses and resolving losses that have already occurred. The Board agrees with the examining division that this model constitutes a business method excluded from patentability under Article 52(2)(c) EPC.

Against this finding, the Appellant argued that the claimed model could be automatically executed on a computer, thereby replacing human experts in performing the risk analysis. While the Board accepts that the claimed invention predicts losses in a different way from a human expert, the Board also found that this difference cannot establish technical character:

4.9 The Board also accepts that the claimed model predicts future losses in a different way from a human expert.

However, it is established case law that a comparison with the prior art, for example with what humans did before the invention, is not a suitable basis for establishing technical character of subject-matter excluded from patentability or for distinguishing between technical and non-technical features (see T 1358/09, Reasons, point 5.4).

As a result, the Board in charge disregarded the above-mentioned distinguishing features in accordance with the COMVIK approach and thus found that the claimed subject-matter lacks inventive step. Hence, the appeal was dismissed.

More information

You can read the full decision here: T 2626/18 (Insurance risk prediction/SWISS RE) of September 28, 2022.

Stay in the loop

Never miss a beat by subscribing to the email newsletter. Please see our Privacy Policy.

* = Required field

Patrick Heckeler

Patrick is a European patent attorney at BARDEHLE PAGENBERG. He specializes in software patents in Europe both from a prosecution and litigation point of view.

www.bardehle.com/team/detail/heckeler-patrick.html

Avoiding redundant displaying of notifications: technical

The application underlying the present decision relates to an arrangement of multiple electronic devices receiving content of internet services. By using a synchronisation server, it is avoided that corresponding notifications are displayed redundantly on the electronic devices. The Board in charge considered the usage of a synchronisation server programmed to track received and viewed notifications based on information received from the user devices technical. Here are the practical takeaways of the decision T 2712/18 (Synchronisation server/APPLE) dated November 14, 2022 of Technical Board of Appeal 3.5.01:

Key takeaways

Technical implementation choices regarding administrative schemes that may not be envisaged by the business person are in the sphere of the technically skilled person.

The invention

The Board in charge summarized the invention underlying the present decision as follows:

1.1 The invention concerns an arrangement in which a user sets up multiple electronic devices (“plurality of associated devices” in the claims), for example a mobile phone and a desktop computer, to receive content (“notifications”) from Internet services ([3] and [18]). Looking at Figure 2, in such an arrangement notifications are provided to local applications 205A-205D by servers 104A-104D (“a first server” and “a second server” in the claims of the third auxiliary request). For example, an email server 104C provides emails to a local email application 205C and a weather server 104D provides weather updates and forecasts to a local weather application 205D ([20]).

The problem with this arrangement is that multiple electronic devices contain overlapping notifications and the user has to sift through notifications which they possibly already viewed on another device ([3] and [33]). The invention seeks to avoid the redundant display of notifications which have already been viewed on one of the user’s devices ([13]).

1.2 Looking at Figure 3, the invention provides a synchronisation server 108 tracking which notifications are received and which user devices they are displayed on ([33]). To this end, the user devices inform the synchronisation server about each received notification ([31] and [32]).

The synchronisation server also receives from a user device an indication that the user selected and viewed a particular notification on it ([41]). Upon receiving such an indication, the synchronisation server sends an indication that the notification has been viewed to each user device on which it is present ([41] to [43]). Upon receipt of this indication, the user devices may remove the viewed notification from a user interface displaying it ([43]).

Fig. 2 of EP 2 669 854 A1

Here is how the invention is defined in claim 1 of the third auxiliary request:

Claim 1 (third auxiliary request)

A method, comprising:

receiving, by a processor (605) of a first device (106A) of a plurality of associated devices, a first notification associated with a first application of the first device and with a first information service provided by a first server;

receiving, by the processor of the first device, a second notification associated with a second application associated with the first device and with a second information service provided by a second server;

communicating, by the first device, to a synchronization server computer system (108) that the first and second notifications have been received;

determining, by the processor (605) of the first device (106A), that the first notification has been viewed on the first device (106A);

sending to the synchronization server computer system, by the processor (605) of the first device (106A), an indication that the first notification has been viewed on the first device (106A) and should be removed from any of the plurality of associated devices on which the first notification is present; and

removing the second notification from a user interface of the first device responsive to an indication from the synchronization server computer system that the second notification has been viewed on one of the plurality of associated devices.

Is it technical?

The first instance examining division considered that the technical aspects of claim 1 of the main request (which generally corresponds to claim 1 of the third auxiliary request that has only submitted during the appeal proceedings with some further limitations) would not go beyond a general purpose networked computer system performing its commonly known functions. Specifically, the task of managing notifications was an administrative one and the steps of receiving and sending notifications and indications did not per se have technical character. In addition, the examining division pointed out that avoiding presenting duplicate notifications to a user was merely an administrative problem (see appeal decision, items 4.2.1 and 4.2.2).

Against this assessment, the applicant argued as follows:

4.2.4 The appellant argued that exchanging messages between the synchronisation server and the user devices was part of the technical solution and the features defining this functionality should be considered for inventive step.

At the appeal stage, the Board in charge generally agreed to the applicant’s arguments:

4.2.7 It is established case law that the business person giving the non-technical requirements to the skilled person does not have technical appreciation of how business concepts are implemented on a computer system (see T 1082/13, Reasons, point 4.8). However, the provision of the synchronisation server and the decision on what electronic messages to communicate in order to remove viewed notifications from the user devices require such understanding of computer technology and involve technical considerations on how this technology can be used to implement the above administrative requirement. These steps have the character of a communication protocol. It follows that these features could not be envisaged by the business person and are technical implementation choices which are in the sphere of the technically skilled person.

Hence, the Board found that claim 1 of the main request comprises several other technical features which applies a fortiori to the narrower independent claim 1 of the third auxiliary request:

4.2.8 Accordingly, the Board judges that the following features of claims 1 and 7 of the third auxiliary request are part of the technical implementation and, therefore, subject to the assessment of inventive step:

– providing a user device programmed to:

– run two applications and to receive notifications

for these applications from two different servers

– inform the synchronisation server which

notifications have been received and which among

them have been viewed

– remove a notification from a user interface on

which it is displayed in response to the

indication, from the synchronisation server, that

the notification has been viewed

– providing the synchronisation server programmed to

track received and viewed notifications based on the

information received from the user devices and to

provide to the user devices the indication that a

notification has been viewed on one of them.

According to the Board, the technically skilled person would not have arrived at the claimed subject-matter when starting from a general purpose networked computer system. Specifically, the features specifying the use of the synchronisation server and the exchanged messages clearly go beyond the routine knowledge of the skilled person (see item 4.2.9 of the appeal decision).

Since the examining division failed to assess the claimed subject-matter with regard to the pertinent prior art, the Board remitted the case back for further examination. Thus, the decision under appeal was set aside.

More information

You can read the whole decision here: T 2712/18 (Synchronisation server/APPLE) of November 14, 2022

Stay in the loop

Never miss a beat by subscribing to the email newsletter. Please see our Privacy Policy.

* = Required field

Patrick Heckeler

Patrick is a European patent attorney at BARDEHLE PAGENBERG. He specializes in software patents in Europe both from a prosecution and litigation point of view.

www.bardehle.com/team/detail/heckeler-patrick.html

Monitoring airport data and automation of cover payments in case of airport closures: non-technical

The application underlying the present decision relates to a system that deals with airport closures and related flight plan changes due to natural disaster events. More specifically, based on given business rules, an automatic payment of financial compensation is paid to the airlines affected by the airport closures. However, the European Patent Office refused to grant a patent since the the relevant features would only refer to a non-technical business scheme. Here are the practical takeaways of the decision T 0524/19 () dated September 16, 2022 of Technical Board of Appeal 3.4.03:

Key takeaways

Policies drawn up by the notional business person are typically non-technical.

The invention

The Board in charge summarized the invention underlying the present decision as follows:

2.1.1 The volcanic activity in Iceland in 2010 and the subsequent closure of airspace led to an estimated loss of 1.7 billion dollars for the airline industry. Between 15 and 21 April 2010 almost the entire European airspace was closed resulting in cancellation of all flights in, to and from Europe. The invention relates to dealing with such airport closures and related flight plan changes due to natural disaster events.

2.2 When aircraft are grounded for more than ten days, airline companies may no longer be able to pay the operating resources (kerosene, salaries, maintenance etc.) due to lack of revenues. It is an aim of the invention to reduce the risk that airline companies go bankrupt due to lack of cash for operation during or after natural disaster events. The airlines seek risk transfer by means of insurance technology to cover such unforeseeable events and to ensure operation of the aircraft fleets. The related technology should be able to cover risk events such as 1) strikes, riots etc.; 2) war, hijacking, terror; 3) pandemic-based risks; 4) extreme weather situations; 5) instabilities in Air Traffic Control (ATC); 6) volcanic ash. However, the covers are technically difficult to design because no standards e.g. for critical ash concentrations exist. It is an object of the invention to provide an automated system preventing imminent grounding of aircraft fleets due to missing financial resources after risk events and to provide a systematic and automated management of risk exposure.

2.3 The invention proposes determining, based on given business rules, the automatic payment of financial compensation to the affected business units, i.e. airlines and their fleets. This object is solved by monitoring relevant airport data, defining critical thresholds, and automation of cover payments in case of airport closures.

Fig. 1 of WO 2014/009415 A1

Here is how the invention is defined in claim 1 of the main request (filed as Annex A):

Claim 1 (main request - labelling added by the Board)

(A) Automated, self-sufficient operatable resource-pooling system (1) for self-adaptive risk sharing of airspace risks related to natural disaster events of a variable number of risk exposed aircraft fleets (81,…, 84) by pooling resources of the risk exposed aircraft fleets (81,…, 84) and by providing a self-sufficient risk protection based on the pooled resources for the risk exposed aircraft fleets (81,…, 84) by means of the resource pooling system (1),

(B) wherein risk exposed aircraft fleets (81,…, 84) are connected to the system (1) by means of a plurality of payment-receiving modules configured to receive and store payments from the risk exposed aircraft fleets (81,…, 84) for the pooling of their risks and resources,

(C) and wherein an automated transfer of risk exposure associated to the aircraft fleets is provided by the resource-pooling system (1), characterized,

(D) in that the system (1) comprises capturing means to receive transmitted fight (sic) plan parameters (102, 202) of the pooled risk exposed aircraft fleets (81,…, 84),

(E) wherein by means of a filter module the transmitted fight (sic) plan parameters (102, 202) are filtered for the detection of airport indicators indicating flown to airports (91,…, 94) by the corresponding pooled risk exposed aircraft fleet (81,…, 84),

(F) and wherein by means of the filtered airport indicators (1012, 2012) detected airports (91,…, 94) are stored to a table element (101, 201) of a selectable trigger-table (103, 203) assigned to an aircraft fleet identifier of the corresponding pooled risk exposed aircraft fleet,

(G) in that the system (1) comprises a trigger module (4) dynamically triggering on an airport data flow pathway of ground stations (911,…, 914) situated at said flown to airports (91,…, 94) based on the stored airport indicators of the trigger-table (103, 203),

(H) wherein the ground stations (911,…, 914) are linked via a communication network (50, 51) to a core engine (2),

(I) in that the core engine (2) comprises a receiver (3) for receiving, via a communication network interface (31), a transmission from the trigger module (4), said transmission including at least parameters regarding a time interval parameter (1011/2011) of an airport closing and an airport identification (1012/2012), wherein the receiver (3) and the ground stations (911, … ,914) comprises (sic) an identification module comprising authentication data relevant for authenticating the receiver (3) and the ground stations (911, … ,914) in the communication network (50,51), wherein the trigger module (4) is dynamically triggering on the airport data flow pathway of the ground stations (911,…, 914) via said communication network (50, 51),

(J) and wherein in case of a triggering of an occurrence of an airport closing of one of the airports (91,. .., 94) comprised in the selectable trigger-table (103, 203), operational parameters of the triggered airport (91,…, 94) comprising at least time interval parameters (1011, 2011) of the airport closing are captured and stored assigned to the corresponding table element (101, 201),

(K) in that for each triggered occurrence of an airport closing of one of the airports (91,…, 94) assigned to a table element (101, 201) of the selectable trigger-table (103, 203), the captured operational parameters of the airport closing are matched with natural disaster event data comprised in a predefined searchable table of natural disaster events in order to relate the airport closing to an occurrence of a natural disaster event comprised in the searchable table of natural disaster events by means of the core engine (2),

(L) wherein the resource pooling system (1) further comprises means for dynamically detecting occurrences of natural disaster events and set appropriate indicator flags in the table element of the corresponding risk together with storing related natural disaster event data and/or measuring parameters indicating at least time of occurrence and/or affected region of the natural disaster event,

(M) and wherein the system (1) is connected to appropriate sensors or measuring devices for the detection of the occurrence of such natural disaster events,

(N) in that the predefined searchable table of natural disaster events comprises table elements for each of the predefined risk transferred to the resource-pooling system (1),

(O) wherein each risk is related to parameters of a table element, defining the natural disaster events, (P) and wherein the resource pooling system (1) further comprises means for dynamically detect (sic) occurrences of such natural disaster events and set appropriate indicator flags in the table element of the corresponding risk together with storing related natural disaster event data and/or measuring parameters indicating at least time of occurrence and/or affected region of the natural disaster event,

(Q) in that in case that a match is established by the core engine (2), a corresponding trigger-flag is set by means of the core engine (2) to the assigned risk exposed aircraft fleets (81,…, 84) of the airport indicator (1012, 2012), and a parametric transfer of payments is assigned to this corresponding trigger-flag,

(R) in that said assignment of the parametric transfer of payments to the corresponding trigger-flag is automated activated by means of the system (1) for a dynamically scalable loss covering of the aircraft fleet (41,…, 44) with an (sic) definable upper coverage limit,

(S1) wherein the payments are automated scaled based on the likelihood of said risk exposure of a specific aircraft fleet (41,…, 44),

(S2) wherein the number of pooled risk exposed aircraft fleets (81,… , 84) is variable and self-adapted by the system 1 to a range where not-covariant occurring risks covered by the system (1) affect only a relatively small proportion of the totally pooled risk exposure of the aircraft fleets 81,… , 84 at a given time,

(T) and wherein said assignment of the parametric transfer of payments is automatedly (sic) activated only, if said transmission comprises a definable minimum number of airport identifications assigned to airport closings thus creating an implicit geographic spread of the closed airports of the flight plan,

(U) and wherein said core engine (2) comprises an additional filter module (5) for dynamically incrementing a time-based stack with the transmitted time interval parameters (1011, 2011) based on the selectable trigger-table (103, 203) and activating the assignment of the parametric transfer of payments to the corresponding trigger-flag by means of the filter module (5) if a threshold, triggered on the incremented stack value, is reached, and

(V) in that a loss associated with the triggered airport closing is distinctly covered by the system (1) based on the respective trigger-flag and based on the received and stored payment parameters from the pooled risk exposed aircraft fleets (81,…, 84) by the parametric payment transfer from the system (1) to the corresponding risk exposed aircraft fleets (81,…, 84) (W) by means of an automated activated damage recovering system (7) automatically operated by an automatically generated output signal of an (sic) failure deployment device (6) of the system (1).

Is it technical?

The Board in charge considered D1 to form the closest prior art for the subject-matter of claim 1 and identified the following distinguishing features, wherein technical ones are presented in italic:

2.6.1 The main differences are therefore (…):

(a) payment-receiving modules;

(b) automated transfer of risk exposure associated to the aircraft fleets is provided (= automated premium payment);

(c) means for receiving flight plan data stored in a selectable trigger-table;

(d) airport closures are matched with natural disaster event data comprised in a predefined searchable table of natural disaster events;

(e) wherein each risk is related to parameters of a table element, defining the natural disaster events,

(f) setting flags in the table of corresponding risk together with storing related natural disaster event data and/or measuring parameters indicating at least time of occurrence and/or affected region of the natural disaster event;

(g) for a match a trigger-flag is set to the assigned risk exposed aircraft fleets of the airport indicator and a parametric transfer of payments is assigned to the trigger-flag;

(h) the payments are automatically scaled based on the likelihood of said risk exposure, the number of pooled risk exposed aircraft fleets is self-adapted;

(i) the payouts are activated only if said transmission comprises a definable minimum number of airport identifications assigned to airport closings thus creating an implicit geographic spread of the closed airports of the flight plan;

(j) a failure deployment device (6) of the system (1) triggers the payout.

Then, the Board identified the effects of said features as follows (technical ones in italic):

2.7 Technical effects

2.7.1 The following (technical/non-technical) effects can be identified:

(a) payment-receiving modules: these means are implicit for any automated payment system; no specific technical effect is related thereto.

(b) automated transfer of risk exposure: these features are purely related to a business method;

(c) means for receiving flight plan data: these means are implicit when dealing with flight plan tables;

(d) a selectable trigger-table for flight plan data: storing flight plan data (in a table) implies that assignments of aircraft to specific airports can be extracted from the table;

(e) airport closures are matched: from the closed airports it can be inferred that a natural disaster has occurred;

(f) natural disaster event table: a time-dependent mapping of the occurrence of a natural disaster can be established;

(g) table with predefined risk: a risk evaluation based on the impact of a natural disaster related to a specific airport/fleet can be performed;

(h) automated and scaled payments: risk evaluation for calculating insurance cover and insurance reimbursement is related to a business method;

(i) geographic spread: mapping of airport closures in combination with the previous features allows matching of airport closures to a specific natural disaster;

(j) failure deployment device of the system: D1 discloses a failure deployment device. Linking the failure deployment device to the automatic payout realises electronically triggered payments.

Specifically with respect to feature (T), the Appellant was of the opinion that this features provides a technical effect:

2.7.2 The Appellant argued that feature (T), namely that an automatic payout can only take place if a minimum number of airport closings created “an implicit geographic spread of the closed airports of the flight plan”, had the technical effect that a certain natural disaster can be inferred from easily ascertainable data (which airport is closed when and where?) without a great deal of computing and detection effort. This did not directly result from the insurance conditions and could not be specified by the notional business person. Consequently, this feature was purely technical.

2.7.3 Since the primary technical effect of feature (T) was that a natural disaster could be detected, it could not be argued that the technical effect was “diminished” by the fact that in the final effect it served exclusively to pay out an insurance premium. In general, the primary technical effect of a non-technical feature could not be diminished by the fact that in the final effect it serves exclusively a non-technical or business purpose. This would be tantamount to imputing technical knowledge to the notional business person. If non-technical features had both a technical and a non-technical effect, the technical effect had to be taken into account when assessing inventive step (see related case T 698/19, catchword).

However, the Board in charge found that feature (T) would only refer to a pure business constraint which is not technical:

2.7.4 However, the Board is of the opinion that, while a trigger feature such as a “minimum number of airport identifications assigned to airport closings” might, in certain contexts, be seen as technical, feature (T) must be assessed as a whole and in the context of the claimed invention. The above trigger condition serves exclusively as a condition that “said assignment of the parametric transfer of payments is automatedly (sic) activated”, hence to implement the insurance policy and initiate the payment.

2.7.5 Feature (T) as a whole does not allow a natural disaster to be “detected” in any technical sense, it is merely an arbitrary rule based on a statistical inference from known data on airport closures. Certainly the notional business person has no knowledge of computer programming or detector design, but this is not what is claimed. The insurance business is based on probability and statistics, and the insurance business person must surely have some knowledge of their own business. Such a person would understand that if only one airport were closed, there is a high probability that it may be due to a local problem, whereas if ten airports in western Europe were closed, it is much more probable that a natural emergency is the cause. If the aim is to insure only against natural emergencies, then looking at previous statistical records would provide a suitable minimum number of airport closures to use in the policy. The Board does not see any technology at work here, it is just a choice by the notional business person drawing up the policy. For example, if, in a given region, the minimum number of airport closures required to trigger a payout is set to four, then if only three airports are closed, there is no payout, even if the closures are actually due to a natural disaster. So it is not a matter of “recognising” a natural disaster in the technical sense, but only a rule for a payout, which therefore has a purely economic effect.

Then, the Board summarized the effects of the distinguishing features as follows:

2.7.7 …

(i) minimum number of airport closures triggers the automated payment; the character of the features concerned is non-technical, the purpose is non-technical (transfer of financial risks)

(ii) identifying type and risk factor of a natural disaster based on flight plan data, airport closures and a natural disaster event table with associated risks; the character of the features concerned is technical, the purpose is both technical (risk evaluation) and non-technical (transfer of financial risks).

(iii) automatisation of payments; the character of the payment means used is technical, the character of the implemented method (features (Q) to (S2), (U), (V)) is non-technical.

Afterwards, the Board found that the notional business person would define the business framework described in the application as follows::

2.8.1 The Board is of the opinion that the notional business person, who does not have any technical knowledge or technical skills, defines in the insurance policy the following business framework conditions for the system:

(a) It must be defined which specific geophysical events (volcano ash, riots, hurricanes, strikes etc.) are covered (or not).

(b) It must further be defined in the insurance conditions which airports/specific regions, which specific time interval and which specific types of event are to be taken into account, e.g. only Eurasian and American airport closures may be taken into account for a minimum of seven consecutive days of closure, financial damage due to strike within the airline company and closures for less than seven days may not be taken into account etc.

(c) Another implicit condition is that only groundings of scheduled aircraft (i.e. according to a flight plan) are considered.

(d) The correlation between the risk factor and the premium payed out must further be defined in the policy.

(e) The scaling factor for the scaled payments must be defined.

(f) As discussed above a further condition may be that payouts are triggered only when a minimum number of aircraft of a fleet is concerned. A clause may be provided that reimbursement is only provided when “clustering” of airport closures occurs, i.e. the payments are only activated if there are massive airport closures and a natural event is classified as a natural disaster (e.g. four airports in a given region).

To solve this problem, the notional business person would simply instruct a computer specialist to program a computer system accordingly:

2.8.2 … In the present case the notional business person (e.g. insurance company in cooperation with the airline companies concerned) instructs a computer specialist with the implementation of an automated system. Their task is to adapt the software in the central computer.

The Board then concluded that the problem to be solved could be formulated as follows, including the wording of the features that it considered non-technical:

2.8.4 The technical problem to be solved therefore can be defined as providing a systematic and automated management of financial and technical risk exposure associated to cancellation of scheduled flights due to airport closures caused by natural disasters, including implementing the claimed non-technical features (Q) to (V).

On the effects (i)-(iii) identified above, the Board commented as follows:

ad (i)

…

2.9.3 The failure of several airports in Germany due to lack of gas, in France due to strike, in Ukraine due to war and in Italy due to earthquake was discussed. These cases may not all be covered by the insurance policy, but it needs a quantitative parameter to determine a “disaster”, and this quantitative parameter is defined in the insurance policy and given by the notional business person to the technically skilled person for implementation. The insurance conditions require monitoring airport closures within defined regions (“geographic spread”), and it would be straightforward for the technically skilled person to arrive at an appropriate means for implementing this in an automatic manner.

ad (ii)

2.9.4 It is (at least implicitly) a non-technical constraint that the amount to be paid out should be dependent on the number of aircraft actually impacted by the airport closures. Therefore, in order to deal with the technical and financial consequences of airport closures, the Board is of the opinion that it is obvious to the skilled person to consider the concerned airports and flight plan routes to and from the closed airports according to a selectable flight plan table (if only scheduled flight are covered by the insurance policy). In view of the objective technical problem to be solved, it is a normal option to monitor which flight plan connection (and therefore which fleets and airlines) are concerned by the closure of specific airports and air-spaces. Furthermore, the emergency system of D3 teaches ([0084]) to take flight plan data into account. The skilled person would therefore adapt the software architecture of D1 and correlate the airport closure events with the flight plan data. Flight plan data is in general available in form of a selectable trigger-table in order to retrieve the data.

2.9.5 It is a normal option to provide a time-dependent mapping of airport closures in relation to the aircraft being concerned and setting a trigger-flag to the assigned risk exposed aircraft fleets of the airport indicator.

2.9.6 Clustering, i.e. a minimum number of aircraft closures in a mapped region, is considered a pre-requisite for payment and a non-technical constraint. Also paying out according to the number of aircraft concerned is a non-technical constraint (see the related case T 288/19). The technically skilled person merely has to solve the (technical) problem of the technical implementation, i.e. the implementation of the business constraints, into the software system. The skilled person would therefore extract the flight plan data accordingly and map the (temporal or geographical) evolution. It is a normal option to monitor which flight plan connections (and therefore which airlines and aircraft) are concerned by the closure of specific airports and to provide a time-dependent mapping of the data (feature (P)).

ad(iii)

2.9.7 Features (Q) to (V), relate to automatically triggering payouts of insurance covers, and directly result from the problem to be solved. Furthermore, the parameterization of the risk evaluation and reimbursement model is ultimately influenced by business requirements (see also reasons 2.13 of T 1798/13).

2.9.8 In T 848/15 (reasons 3.2) it was held that insurance risk management related exclusively to economic considerations in the framework of purely economic models defined by an economist and therefore was not inventive within the meaning of Article 56 EPC (cf. also T 698/19, reasons 3.8.2 ff). Accordingly, non-technical features purely relating to an insurance model (e.g. non-technical part of features (b), (h) to (j) in the present case, see point 2.7.1 above) are obvious for the same reasoning.

…

Against this background, the Board found that claim 1 lacks inventive step and thus dismissed the appeal.

More information

You can read the whole decision here: T 0524/19 () of September 16, 2022

Stay in the loop

Never miss a beat by subscribing to the email newsletter. Please see our Privacy Policy.

* = Required field

Patrick Heckeler

Patrick is a European patent attorney at BARDEHLE PAGENBERG. He specializes in software patents in Europe both from a prosecution and litigation point of view.

www.bardehle.com/team/detail/heckeler-patrick.html

Presenting information of interest to a user based on a user profile: non-technical

The application underlying the present decision relates to a system with the ability to self-configure after the installation of new data sources. However, the European Patent Office refused to grant a patent since the the distinguishing features would only refer to the mere presentation of information. Here are the practical takeaways of the decision T 2021/17 (Intelligent agents/UNIVERSITY of STRATHCLYDE) dated October 7, 2021 of Technical Board of Appeal 3.5.01:

Key takeaways

The customisation of information to be displayed according to the interest of a user is not technical.

The invention

The Board in charge summarized the invention underlying the present decision as follows:

1.1 The invention concerns monitoring the condition of hardware and/or machines, such as transformers in a power station (see Figure 17 of the published application).

Data from e.g. vibration or temperature sensors (“condition data sources”) is processed in a “conditioning monitoring platform” and displayed via a user interface. The objective is to dynamically adapt to new data sources and processing capabilities without the user having to search for new features (paragraph bridging pages 25 and 26).

This is achieved by using “intelligent agents”, which are software entities that act autonomously to achieve goals based on the environment (see e.g. page 8, lines 20ff.). Such agents are said to react to changes in the environment (reactivity – R), work without external prompting (pro-activity – P) and interact with other agents (social ability – S).

Fig. 1 of WO 2011/045571 A1

Here is how the invention is defined in claim 1 of the third auxiliary request:

Claim 1 (third auxiliary request)

A computer based conditioning monitoring system configured to monitor the condition of physical hardware and/or at least one machine, the system comprising:

a plurality of condition data sources adapted to provide condition data relating to the machine and/or physical hardware;

a user interface for presenting condition data to a user;

a conditioning monitoring platform operable to communicate with the plurality of data sources and the user interface, the conditioning monitoring platform comprising:

a plurality of user assistants implemented by a first class of software agents, each user assistant being operable to determine condition data of interest to a user by presenting to the user a plurality of user selectable options based on available data, and receiving one or more user selections by presenting a plurality of high
level options to a user, each option being associated with a plurality of related, more specific options, wherein on selection of one of the high level options the other more specific options are presented; and each user assistant being further operable to build and store a user profile based on the condition data of interest; each user assistant being configured to change the user profile by updating the user profile in response to receipt of information on a new user interest and/or in response to at least one user input;

a user translator for translating information received from the user into a form interpretable by the computer based system and translating information received from the computer based system into a form interpretable by the user;

a plurality of data managers implemented by a second class of software agents, at least one associated with each condition data source, each data manager adapted to provide access to its associated data source; to identify when new data is added to its associated data source; and to communicate data to user assistants that have a user profile that indicates the data is of interest, wherein when a new condition data source becomes available a new associated data manager is added; and

a plurality of service managers implemented by a third class of software operable to access data made available by the data managers, each service manager operable to provide an analysis of data using one or more data analysis functions, each service manager having knowledge of the type of data required to perform its analysis function, and being operable to communicate with user assistants that have that data in their user profile;

the system is configured to allow the addition of one or more new data analysis functions and an associated service manager; and

the user assistant is adapted to search for and match the service managers that provide data analysis functions with its associated user based on the user profile, and/or the plurality of service managers being adapted to search for and match with one or more user assistants based on the user profiles.

Is it technical?

Since the third auxiliary request provides the narrowest scope, the Board in charge directed its assessment to this request. According to the Board, in accordance with the Appellant’s view, D1 forms the closest prior art for the subject-matter of claim 1 of the third auxiliary request. The Board identified the following distinguishing features over D1:

2.6 In the Board’s view, D1 does not disclose dynamically building a user profile based on the interests of the user. There is no mechanism for interacting with the user by presenting user selectable options and receiving user selections. …

Another difference is that, while in D1 the different functions are all preformed by the same agent, the tasks are in claim 1 divided between “user assistants”, “data managers”, “service managers” which communicate with each other. …

In D1, when a new data source is added, a new agent is added to handle it. In claim 1 of the third auxiliary request, when a new data source is added, an associated data manger is added. The claimed system also allows the addition of one or more data analysis functions and an associated service manager. …

Based on the above-identified distinguishing features, the Board in charge discussed the existence of a technical effect concerning these features as follows:

2.7 The question is what technical effect, if any, is provided by the user profile and the division of tasks and interaction between the various agents.

In the Board’s view, presenting information of interest to the user based on a user profile is not technical, and cannot therefore contribute to inventive step under the “Comvik approach” (see T 641/00 – Two identities/COMVIK). …

Specifically, the Board found that this kind of customization of the data to be presented is only based on the interest of the user:

Although the presentation of information relating to a technical condition in an apparatus or system may arguably be regarded as technical (see e.g. T 115/85 – Computer-related invention and T 528/07 – Portal system/ACCENTURE), the Board does not consider that the technical character extends to the customisation of such information. The customisation is not based on any technical criteria, but merely on the interest of the user.

Against this view, the Appellant argued that the invention would, besides the customization of what is shown to the user, control communication between the claimed data managers and user assistants to provide better data. However, the Board did not follow this argument:

2.9 The Board does not see that this is a technical effect that could support the presence of an inventive step. In any personalised information system, the user profile determines how the system responds. The particular organisation of tasks, and the interaction between the various agents is, in the Board’s view a matter of software implementation.

In addition, the application underlying the present decision would lack any technical definition that could distinguish the claimed agents from a common software implementation:

The Board notes that there is no definition for what an agent is in terms of technical properties either in the application or even generally in the art (see D1, II.A). Thus, the agents in claim 1 cannot be distinguished from software modules suitable for implementing the desired functions. In the Board’s view, the internal structure of a computer program, for example the particular configuration of software modules, objects, or, indeed, “agents”, does not provide a further technical effect in the sense of T 1173/97 – Computer program product/IBM, i.e. an effect that goes beyond the normal effects of running software on a computer.

Hence, in the Board’s view, the distinguishing features could not provide any technical effect. As a result, and because the main and the first and second auxiliary requests cover the subject-matter of claim 1 of the third auxiliary request, the appeal was dismissed due to lack of inventive step according to the COMVIK approach.

More information

You can read the whole decision here: T 2021/17 (Intelligent agents/UNIVERSITY of STRATHCLYDE)

Stay in the loop

Never miss a beat by subscribing to the email newsletter. Please see our Privacy Policy.

* = Required field

Patrick Heckeler

Patrick is a European patent attorney at BARDEHLE PAGENBERG. He specializes in software patents in Europe both from a prosecution and litigation point of view.

Key takeaways

The invention

Claim 1 of the Main Request

Is it patentable?

More information

Stay in the loop

Key takeaways

The invention

Claim 8 of the Main Request

Is it patentable?

More information

Stay in the loop

Key takeaways

The invention

Claim 1 of the Main Request

Is it patentable?

More information

Stay in the loop

Key takeaways

The invention

Claim 1 of the fifth Auxiliary Request

Is it patentable?

More information

Stay in the loop

Key takeaways

The invention

Claim 1 of the first Auxiliary Request

Is it patentable?

More information

Stay in the loop

Key takeaways

The invention

System Claim 1 of Main Request

Is it patentable?

More information

Stay in the loop

Key takeaways

The invention

System Claim 1 of Auxiliary Request I

Is it patentable?

More information

Stay in the loop

Key takeaways

The invention

Claim 1 (third auxiliary request)

Is it technical?

More information

Stay in the loop

Key takeaways

The invention

Claim 1 (main request - labelling added by the Board)

Is it technical?

More information

Stay in the loop

Key takeaways

The invention

Claim 1 (third auxiliary request)

Is it technical?

More information

Stay in the loop

Latest Knowledge Base Entries