Citation: Neoteric Technology Limited (Re), 2020 CACP 32

Commissioner’s Decision #1552

Décision du Commissaire #1552

Date: 2020-12-01

 

TOPIC:	O00	Obviousness
SUJET:	O00	Évidence

 

Application No. : 2,555,713

Demande no 2 555 713

 

IN THE CANADIAN PATENT OFFICE

 

 

 

DECISION OF THE COMMISSIONER OF PATENTS

 

 

 

Patent application number 2,555,713, having been rejected under subsection 30(3) of the Patent Rules (SOR/96-423) as they read immediately before October 30, 2019 (“former Rules”) has consequently been reviewed in accordance with paragraph 199(3)(c) of the Patent Rules (SOR/2019-251) (“Patent Rules”). The recommendation of the Board and the decision of the Commissioner are to withdraw the rejection and allow the application.

Agent for the Applicant:

SMART & BIGGAR LLP

2300-1055 West Georgia Street

VANCOUVER, British Columbia

V6E 3P3

 

INTRODUCTION

[1] This recommendation concerns the review of rejected Canadian patent application number 2,555,713 (“the instant application”), which is entitled “APPARATUS AND METHODS FOR MONITORING TRANSFUSION OF BLOOD” and is owned by NEOTERIC TECHNOLOGY LIMITED (“the Applicant”). A review of the rejected application has been conducted by the Patent Appeal Board (“the Board”) pursuant to paragraph 199(3)(c) of the Patent Rules. As explained in more detail below, our recommendation is that the rejection be withdrawn and the application be allowed.

BACKGROUND

The Application

[2] The instant application was filed under the Patent Cooperation Treaty and has an effective filing date in Canada of February 18, 2005. It was laid open to public inspection on September 1, 2005.

[3] The instant application relates to a method and apparatus for providing a complete tracking and verification system for blood and/or blood products as they progress through sample taking, compatibility testing, blood unit requests, transportation, and transfusion. The method and apparatus comprise multiple verification steps to ensure that blood products are not administered to the wrong patient.

Prosecution History

[4] On January 15, 2018, a Final Action (“FA”) was written pursuant to subsection 30(4) of the former Rules. The FA stated that the instant application is defective on the ground that all of the claims 1-11 on file at the time of the FA (“claims on file”) would have been obvious and therefore do not comply with section 28.3 of the Patent Act.

[5] In a July 6, 2018 response to the FA (“R-FA”), the Applicant submitted arguments in favor of the patentability of the claims on file. The Applicant also proposed amendments to the description and to the claims on file (“proposed claim set-1”).

[6] As the Examiner considered the application not to comply with the Patent Act, pursuant to paragraph 30(6)(c) of the former Rules, the application was forwarded to the Board for review on September 14, 2018 along with an explanation outlined in a Summary of Reasons (“SOR”). The SOR set out the position that the claims on file were still considered to be defective due to obviousness and that proposed claim set-1 did not overcome the defect.

[7] In a letter dated September 25, 2018, the Board forwarded to the Applicant a copy of the SOR and requested that the Applicant confirm its continued interest in having the application reviewed.

[8] In a letter dated September 26, 2018, the Applicant expressed continued interest in having the application reviewed.

[9] The present panel (“the Panel”) of the Board was formed to review the instant application under paragraph 199(3)(c) of the Patent Rules.

[10] In a preliminary review letter (“PR letter”) dated July 6, 2020, the Panel set out its preliminary analysis of the obviousness issue with respect to the claims on file. The PR letter provided a preliminary analysis of proposed claim set-1, indicating that this proposed claim set would not overcome the obviousness defect. The PR letter set out a proposed hearing date and due date for written submissions.

[11] In a response to the PR letter dated August 10, 2020 (“R-PR”), the Applicant submitted arguments in favor of the non-obviousness of the claims on file. The Applicant also provided a new proposed claim set consisting of proposed claims 1-18 (“proposed claim set-2”) for consideration.

[12] An oral hearing via videoconference was held on September 17, 2020.

[13] In response to clarity concerns regarding the language of proposed claim set-2 raised by the Panel at the oral hearing, the Applicant, in a supplemental response dated October 6, 2020 (“SR-PR”) proposed a further claim set consisting of proposed claims 1-20 (“proposed claim set-3”). As the Panel advised the Applicant at the oral hearing, only the most current proposed claim set, namely proposed claim set-3, would be considered if the Panel concluded that the claims on file would have been obvious.

ISSUES

[14] The sole issue to be addressed is whether claims 1-11 on file would have been obvious.

[15] If, after considering the claims on file, the Panel concludes that they would have been obvious, then we would consider proposed claim set-3 to determine whether they constitute amendments necessary for compliance with the Patent Act and Patent Rules, pursuant to subsection 86(11) of the Patent Rules.

LEGAL PRINCIPLES AND OFFICE PRACTICE

Claim Construction

[16] In accordance with Free World Trust v Électro Santé Inc, 2000 SCC 66, essential elements are identified through a purposive construction of the claims done by considering the whole of the disclosure, including the specification and drawings (see also Whirlpool Corp v Camco Inc, 2000 SCC 67 at paras 49(f) and (g) and 52. This is performed from the point of view of the person skilled in the art in light of the relevant common general knowledge (“CGK”).

Obviousness

[17] The Patent Act requires that the subject-matter of a claim not be obvious to a person skilled in the art. Section 28.3 of the Patent Act states:

28.3 The subject-matter defined by a claim in an application for a patent in Canada must be subject matter that would not have been obvious on the claim date to a person skilled in the art or science to which it pertains, having regard to

(a) information disclosed more than one year before the filing date by the applicant, or by a person who obtained knowledge, directly or indirectly, from the applicant in such a manner that the information became available to the public in Canada or elsewhere; and

(b) information disclosed before the claim date by a person not mentioned in paragraph (a) in such a manner that the information became available to the public in Canada or elsewhere.

[18] In Apotex Inc v Sanofi-Synthelabo Canada Inc, 2008 SCC 61 [Sanofi] at paragraph 67, the Supreme Court of Canada stated that it is useful in an obviousness inquiry to use the following four-step approach:

(1)(a) Identify the notional “person skilled in the art”;

(b) Identify the relevant common general knowledge of that person;

(2) Identify the inventive concept of the claim in question or if that cannot readily be done, construe it;

(3) Identify what, if any, differences exist between the matter cited as forming part of the “state of the art” and the inventive concept of the claim or the claim as construed;

(4) Viewed without any knowledge of the alleged invention as claimed, do those differences constitute steps which would have been obvious to the person skilled in the art or do they require any degree of invention?

ANALYSIS

Claim Construction

The person skilled in the art

[19] In the PR letter at page 4, we set out our preliminary identification of the skilled person:

In the FA at page 2 under the assessment of obviousness, the person skilled in the art was set out:

The skilled person, who may be a team of people, is skilled in the field of transfusion of blood and/or blood products (see present description, page 1, lines 9 to 10).

The skilled person is also skilled in the field of general purpose computing technology including electronically readable indicia.

In light of the technical field of the invention set out on page 1 of the instant application and the background discussion in the “Background of the Invention”, in our preliminary view, the skilled person is not limited to the field of blood transfusion. In our preliminary view the person skilled in the art is appropriately characterized as:

∙ a team comprising persons skilled in the areas of handling, tracking, transportation and transfusion of blood and/or blood products. The team would also include persons skilled in the field of general purpose computing technology including electronically readable indicia, as well as patient information storage systems such as blood bank computer systems.

[20] The Applicant did not dispute the above in the R-PR, SR-PR or at the oral hearing. We therefore proceed on this basis.

The relevant common general knowledge

[21] In the PR letter at page 4, we reviewed and preliminarily adopted the relevant CGK as set out in the FA:

In the FA at page 2, the relevant CGK was set out:

The person skilled in the art would understand that blood transfusion is a high- risk procedure and that considerable care must be taken in the collection, processing, packaging, labelling and transport of blood units (see present description, page 1, lines 17 to 20). The skilled person would be expected to have knowledge of prior art blood transfusion procedures as outlined on pages 1 to 3 of the present description. This includes the various checks and audits as described on pages 1 to 3, and the various labels such as wristbands, blood unit identification, compatibility labels. It is also well known to make sure that the label applied to the blood sample matches the information on the patient's wristband.

Blood unit request slips are also common general knowledge in the art.

Barcodes are well-known means of electronically representing information.

The person skilled in the art would also be expected to have knowledge of computer systems for reading and comparing electronic indicia. As the computer system itself is not described in any detail, it is also presumed that the implementation would have been straightforward to a person skilled in the art.

We take the last statement in the quote above to mean that the relevant CGK would include sufficient knowledge of computer systems and associated components necessary to implement the steps of the disclosed and claimed method.

In the R-FA, the Applicant did not dispute the above points of CGK and we preliminarily adopt them for the purpose of this review.

[22] We also set out at page 5 of the PR letter additional points of CGK taken from the prior art of record and from the instant application. We further set out an additional prior art document from which we derived further points of CGK:

In addition to the points of CGK above, we additionally identify the following points of CGK:

∙ knowledge of well-known systems for tracking and labelling blood products and the inadequacies associated with them, such as those identified in the instant application at page 3, line 33 to page 4, line 10, including the Safe Track system;

∙ knowledge of past attempts to improve the transfusion process itself, such as the Safe Track system, including the use of barcode labels and scanners, and the deficiencies in these attempts, such as lack of confirmation of transfusion and lack of means to ensure proper storage and transportation within acceptable time limits, as described on page 4, lines 11-20 of the instant application;

∙ the use of machine-readable data on patient wristbands, such as a PDF barcode used to encode information such as hospital number, name, date of birth and sex of a patient (from reference of interest D5 cited in the FA describing the Safe Track system: Haggas, "Are we transfusing the right patient?", the Transfusion Science Lecture, IBMS Congress 2001 at page 2);

∙ verification steps in the matching and dispensing of blood products, such as prior to transfusion, scanning a user’s ID, a patent ID and the compatibility label on a blood unit, as well as the bar code on the blood unit, in order to verify that all information matches and outputting an alarm if it does not (D5, above at page 2); and

∙ systems for tracking blood units in and out of fridges that can track who removes units, which units are taken and when, how long a unit is out of a fridge, if it was returned or transfused, and if transfused to whom (D5, above at page 2).

During our review, the Panel also identified the following document:

D8: DIRECTIVE 2002/98/EC OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of 27 January 2003 setting standards of quality and safety for the collection, testing, processing, storage and distribution of human blood and blood components and amending Directive 2001/83/EC

D8 at Annex III describes standard blood product labelling requirements in effect at the time, which we take to have also been part of the relevant CGK. The labelling requirements include:

∙ the official name of the component;

∙ the volume or weight or number of cells in the component (as appropriate);

∙ the unique numeric or alphanumeric donation identification;

∙ the name of producing blood establishment;

∙ the ABO Group (not required for plasma intended only for fractionation);

∙ the Rh D Group, either Rh D positive or Rh D negative (not required for plasma intended only for fractionation);

∙ the date or time of expiry (as appropriate);

∙ the temperature of storage; and

∙ the name, composition and volume of anticoagulant and/or additive solution (if any).

[23] None of the above has been disputed by the Applicant in the R-PR, SR-PR or at the oral hearing. We therefore proceed on the basis of the relevant CGK as identified in the PR letter.

Claim language and essential elements

[24] In the PR letter at pages 6-7, we indicated that there were no issues regarding the meaning of any claim terms and that we considered all the claim elements in our analysis. We also set out the subject-matter of the claims:

The claims on file include two independent claims 1 and 7. Claim 1 is directed to a method for tracking blood transfusions and is reproduced below:

1. A method for tracking blood transfusions, said method comprising the steps of:

(a) obtaining identifying information for a patient and providing said patient with a wristband comprising said patient identifying information;

(b) collecting a blood sample from said patient and testing said blood sample to determine a type of blood required by the patient;

(c) allocating, from a supply of blood units, a blood transfusion unit for the patient, wherein said blood transfusion unit contains the type of blood required by said patient and wherein said blood transfusion unit is marked with a transfusion unit identifying code;

(d) labeling said allocated blood transfusion unit with a compatibility label, wherein said compatibility label comprises said patient identifying information and said transfusion unit identifying code;

(e) generating a blood unit request slip for the patient, the blood unit request slip including a request slip identifying code encoding said patient identifying information and the type of blood required;

(f) retrieving the blood transfusion unit and verifying the blood transfusion unit's identity by comparing the patient identifying information encoded in the request slip identifying code to the patient identifying information on the compatibility label on the patient allocated blood transfusion unit;

(g) comparing the patient identifying information from the wristband to the patient identifying information on the compatibility label on said patient allocated blood transfusion unit; and

(h) comparing the transfusion unit identifying code marked on the patient allocated blood transfusion unit with the transfusion unit identifying code on the compatibility label on said patient allocated blood transfusion unit.

Independent claim 7 is similar to 1, but includes a step where patient information is scanned from the patient wristband and used to print a label for the blood sample. Claim 7 also specifies the transmission of patient information read from a wristband, the blood unit identification code read from the blood unit, and the patient identification information and blood unit identification code read from the compatibility label to a computer database.

Whereas claim 1 specifies the creation of a blood unit request slip and the comparison of its information with that on a compatibility label, claim 7 only specifies the creation of the blood request slip without specifying its use. Further, claim 7 specifies the provision of an alarm in cases where scanned information does not match.

The subject-matter of the dependent claims will be reviewed below as part of the Sanofi obviousness assessment.

[25] None of the above was disputed by the Applicant in the R-PR, SR-PR or at the oral hearing.

[26] For the obviousness assessment below, we have considered all the elements of the claims to be essential, there being no indication in the record or the claims themselves that the essentiality of any elements is at issue.

[27] At the hearing, although it was not an issue in this case, the Applicant wished to make note for the record of their objection to the problem/solution approach to claim construction as set out in the Manual of Patent Office Practice [MOPOP], §12.02 (revised June 2015).

Obviousness

(1)(a) Identify the notional “person skilled in the art”

[28] The person skilled in the art has been identified above under Claim Construction.

(1)(b) Identify the relevant common general knowledge of that person

[29] The relevant CGK has also been identified under Claim Construction.

(2) Identify the inventive concept of the claim in question or if that cannot readily be done, construe it

[30] As indicated in the PR letter, we have considered all the elements of the claims on file in our assessment of obviousness and proceed on that basis below.

(3) Identify what if any differences exist between the matter cited as forming part of the “state of the art” and the inventive concept of the claim or the claim as construed

[31] In the FA at page 1, the following prior art documents were applied against the claims on file:

D3: LEWIS, C., "Trails of blood", Health Service Journal, UK, 18 September 2003, pp. 28 - 29.

D6: Web page, http://dataloguk.com/blood_management.htm, June 2003.

Retrieved from the Internet using the Internet Archive wayback machine, http://web.archive.org.

D7: Ashford et al., "Guidelines for blood bank computing", Transfusion Medicine, 2000, vol. 10, pages 307-314.

[32] In the PR letter at pages 8-10, we considered the differences between the claims on file and prior art document D3, as was done in the FA. In response to the Applicant’s request for clarification at the oral hearing, we indicated that the comparison presented on page 8 of the PR letter and quoted below was meant to reflect the comparison in the FA and not our overall preliminary view of the differences, which we set out in the paragraphs following the FA comparison. As part of our preliminary assessment, we identified an additional difference with respect to D3 (the three differences with respect to claim 1 on file are emphasized in bold in the quotation below):

The FA presented a comparison between the features of claim 1 and those disclosed by D3. We present this comparison below, with some material having been added based on our own review of the document (see material in italics):

a) obtaining patient identifying information for a patient (D3: page 28, left-hand column, Information includes the patient's surname, first name, date of birth, sex and hospital number) and providing said patient with a wristband comprising said patient identifying information (D3: page 28, left-hand column, “patients are issued with a barcoded identification wristband on admission to the hospital”);

b) collecting a blood sample from said patient and testing said blood to determine the type of blood required by the patient (D3: page 28, left-hand column, “When a blood sample is taken for compatibility [checking], the phlebotomist uses a hand-held scanner to read the patient’s identification details, prints out a label and attaches it to the sample. Later, the sample is analysed and cross-matched by the central blood bank an a matching barcode label attached to the appropriate blood bag”);

c) allocating from a supply of blood units a blood transfusion unit for the patient wherein said blood transfusion unit contains the type of blood required by said patient (D3:page 28, left-hand column, “Later, the sample is analysed and cross-matched by the central blood bank”) and wherein said blood transfusion unit is marked with a transfusion unit identifying code (D3: page 28, left-hand column, “the unit number on the bag”);

d) labelling said allocated blood transfusion unit with a compatibility label, wherein said compatibility label comprises said patient identifying information and said transfusion unit identifying code (D3: page 28, left-hand column, “Later, the sample is analysed and cross-matched by the central blood bank and a matching barcode label is attached to the appropriate blood bag ... the compatibility label on the blood bag”);

g) comparing the patient identifying information from the wristband to the patient identifying information on the compatibility label on said patient allocated blood transfusion unit (D3: page 28, left-hand column, “When the blood is delivered to the patient for transfusion, the nurse scans in the barcodes on her own staff identification pass, the patient's wristband, the compatibility label on the blood bag and the unit number on the bag If the blood bag is not the correct one for the patient, or there is another problem, the computer flashes 'Do not transfuse' on-screen and sounds an alarm”); and

h) comparing the transfusion unit identifying code marked on the patient allocated blood unit with the transfusion unit identifying code on the compatibility label on said patient allocated blood transfusion unit (D3: page 28, left-hand column, “When the blood is delivered to the patient for transfusion, the nurse scans in the barcodes on her own staff identification pass, the patient's wristband, the compatibility label on the blood bag and the unit number on the bag If the blood bag is not the correct one for the patient, or there is another problem, the computer flashes 'Do not transfuse' on- screen and sounds an alarm.”).

In light of our preliminary review of D3, it is not clear to us that D3 discloses the inclusion of the “transfusion unit identifying code” as part of the information on the compatibility label, as is specified in step (d) of claim 1 on file.

In the R-FA at page 5, the Applicant questioned the information that would have been part of the compatibility label of D3, stating “While D3 uses the term "compatibility label" it does not suggest what specific information should be on a compatibility label.”

In D3 at page 28, it is disclosed that:

patients are issued with a barcoded identification wristband on admission to hospital. Information includes the patient’s surname, first name, date of birth, sex and hospital number.

The information stored on the patient’s wristband is then used to label a sample drawn from the patient that is to be sent for compatibility testing:

When a blood sample is taken for compatibility checking, the phlebotomist uses a hand-held scanner to read the patient’s identification details, prints out a label and attaches it to the sample.

Once the blood sample has been analysed and cross-matched by a central blood bank a “matching” barcode label is attached to the appropriate blood bag:

Later, the sample is analysed and cross-matched by the central blood bank and a matching barcode label attached to the appropriate blood bag.

The “matching” barcode label is referred to as “the compatibility label” at the point where blood is delivered to a patient for transfusion:

When the blood is delivered to the patient for transfusion, the nurse scans in the barcodes on her own staff identification pass, the patient’s wristband, the compatibility label on the blood bag and the unit number on the bag. [Emphasis added]

We agree with the Applicant that D3 does not explicitly specify the information that is included on the compatibility label. However, it is described as a “matching” barcode label in relation to the label that is applied to a patient’s blood sample. In that context, it is our preliminary view that the person skilled in the art would take D3 as disclosing a compatibility label that includes the patient’s identification details, particularly those that are specified for the patient wristband.

Further, in view of this interpretation of the compatibility label information, it is our preliminary view that D3 does not disclose the inclusion of a “transfusion unit identifying code” as part of the compatibility label. Since the information would, in our preliminary view, match that of the patient wristband, it would not include blood unit number information.

In addition to the transfusion unit identifying code as part of the compatibility label, in the FA at page 5, the differences between claim 1 on file and D3 were identified as:

e) generating a blood unit request slip for the patient, the blood unit request slip including a request slip identifying code encoding said patient identifying information and the type of blood product required; and

f) retrieving the blood transfusion unit and verifying the blood transfusion unit's identity by comparing the patient identifying information encoded in the request slip identifying code to the patient identifying information on the compatibility label on the patient allocated blood transfusion unit.

We note that with respect to claim 7, there is no comparison performed between the information on the request slip and that of the compatibility label. Therefore step (f) is not a difference with respect to claim 7.

The additional elements of the dependent claims will be assessed as necessary in step (4) below.

[33] The Applicant did not dispute the differences as identified in the PR letter in the R-PR or SR-PR. With respect to the first difference identified in the PR letter, we also note that since the source of information for the compatibility label in D3 is the information taken from the label that is applied to a patient’s blood sample by the phlebotomist, D3 would not have been understood by the skilled person as including any transfusion unit identifying code as part of the compatibility label. Since no transfusion unit identifying code would have been known at the time of blood sampling and labelling, it could not have been part of the “matching barcode label” later applied in D3 after cross-matching.

[34] At the oral hearing, the Applicant generally agreed that, consistent with the analysis above, although not explicitly stated in D3, the document would probably be interpreted by the skilled person as disclosing that the patient’s identification details are included in the compatibility label, as we indicated in the PR letter, quoted above. This was based on the premise that the information on the compatibility label was a “matching barcode label” to that found on the blood sample taken from a patient, which itself contained the patient information.

[35] The Applicant also generally agreed at the hearing that the blood bag in D3 contains two labels, the compatibility label and the label containing the blood unit number.

[36] As there is no evident difference of opinion regarding the differences with respect to D3, we proceed on the basis of those identified in the PR letter.

(4) Viewed without any knowledge of the alleged invention as claimed, do those differences constitute steps which would have been obvious to the person skilled in the art or do they require any degree of invention?

[37] In the PR letter at pages 10-11, we set out our preliminary view that having considered prior art documents D6 and D7, D6 was, in our view, the most relevant and would be considered in combination with D3. We described the content of D6:

As the Applicant has acknowledged in the R-FA at page 3, D6 is an archived web publication by the Applicant containing several linked webpages that discuss a system known as “Blood Track.” One of the pages shows a diagram of a system in which Blood Track is implemented, shown below:

 

As shown in the above diagram, like D3, the system uses a patient wristband that is scanned when a blood sample is to be taken. The blood sample is then collected and cross-matched in order to identify suitable blood units, which units are labelled with a compatibility label. The blood units with the compatibility label are stored in a fridge until needed. The diagram also shows that blood units may be requested and removed from the fridge.

A verification step takes place when the blood units are to be transported where the blood unit label is scanned and the donation number, product type and expiry date are read. The system can also be configured to request patient information at this stage (see webpage labelled “How does Blood Track work?”). In addition to the scanning of the compatibility label, patient information from the request form is scanned and the system ensures that the blood unit is the correct one for the patient. In the R-FA at page 3, the Applicant confirmed that the reference to a request form is to a “generic paper-type of request form used by hospitals to indicate that the physician has ordered a transfusion for a patient.”

As shown in the diagram, when a blood unit is to be transfused, the patient wristband information and the compatibility label on the blood unit are scanned to confirm a blood match before transfusion may proceed.

The system tracks how long a blood unit is out of storage and provides warnings if one is removed from a fridge and is not safe to use. The system further provides “detailed reports, including unit histories, refrigerator inventories, and current locations of all blood units” (see webpage labelled “What can Blood Track do for me?”).

D6 therefore discloses a blood tracking system similar to that disclosed in D3, but with a greater level of detail. It is our preliminary view that a person skilled in the art would, upon review of a document such as D3, which is a very high level description of a blood tracking system, look to a reference such as D6 for more detailed information regarding the implementation of such a system.

[38] In the PR letter, we considered the three differences with respect to claim 1 on file in turn and their effect on the patentability of the claims. We proceed in the same manner below. We note however that in the R-PR at pages 3-8, the Applicant responded to the first difference in two separate sections A and B, one concerning the information present on the compatibility label and the other concerning the subsequent comparison of this information with that of the label containing the separate transfusion unit identification code on the blood transfusion unit. These submissions and those related to them at the oral hearing will be addressed as part of the first difference.

Compatibility label information

[39] In the PR letter at page 11, we set out our preliminary view that the inclusion of a “transfusion unit identifying code” as part of a compatibility label attached to a blood unit bag was disclosed by D6 and considered that the inclusion of such a feature in a blood tracking system such as that of D3 would have been obvious:

In D6, as shown in the diagram above from that reference, several pieces of information are scanned and compared in order to ensure that a blood unit removed from a fridge is the correct one for a patient. The blood unit compatibility label is scanned upon removal from a fridge where “donation number, the product type and the expiry date” (see webpage labelled “How does Blood Track work?” at step 4) are read. In our preliminary view, the donation number is equivalent to the “transfusion unit identifying code” of the claims, which are both designations of the blood unit bag itself, rather than any patient with which it may be associated. As such, in our preliminary view, D6 shows the inclusion of a “transfusion unit identifying code” as part of the compatibility label and the inclusion of such information in a blood tracking system compatibility label would have been obvious in light of D3 and D6, considered in light of the relevant CGK.

[40] It was the Panel’s preliminary view in the PR letter that because D6 disclosed the attachment to a blood unit of a compatibility label, and that because when a blood unit was to be removed from a fridge, a scanning step took place that read information including “donation number, the product type and the expiry date”, the inclusion of a “transfusion unit identifying code” (i.e., donation number) in a compatibility label such as that of D3, and the subsequent comparison of this information with that of the separate blood unit label, would have been obvious.

[41] The discussion of the scanning step in D6 is focussed on what is disclosed as step 4 in the webpage labelled “How does Blood Track work?”, which is one of the webpages that comprise the D6 prior art document.

[42] In the R-PR at page 6, the Applicant contends that the mere disclosure:

that the blood units may be scanned under a barcode scanner to read the donation number and the product type does not necessarily disclose that the barcode scanner is reading a compatibility label which includes both patient identifying information and a transfusion unit identifying code as required by the present independent claims. [Emphasis in original]

[43] The Applicant contended in the R-PR and at the oral hearing that the scanning step of D6 may in fact be scanning a separate label that identifies the blood transfusion unit itself, such as the separate label of the claims on file that contains the transfusion unit identifying code, rather than the compatibility label. The Applicant contended at page 6 of the R-PR that:

the PAB does not address how one of ordinary skill in the art, when reading the disclosure of D6, would automatically arrive at the conclusion that the barcode scanner would be scanning the compatibility label, rather than the separate transfusion unit identifying code (or blood unit identification code) marked on the blood unit at step 4 above. [Emphasis in original]

[44] In connection with the above contentions, at the hearing the Applicant argued that in any blood unit tracking system, there would always be a label affixed to blood units that would contain a blood unit ID number, separate from any compatibility label, which itself could be read or scanned. This is the case in D3 where the blood unit includes a separate scannable unit number that would be affixed after blood donation and before the attachment of any compatibility label.

[45] Upon further consideration, we agree that although not described in D6, this separate blood unit ID number would have been an inherent characteristic of such a system and the D6 prior art document would have been interpreted as such by the skilled person. This position is consistent with the relevant CGK identified above in relation to D8, which describes standard blood product labelling requirements.

[46] Given the above, D6 would have included both a compatibility label and one identifying the blood unit itself. While it was our position in the PR letter that the scanning step 4 of D6 referred to scanning of the compatibility label, upon reconsideration, we are of the view that this is not clear from the D6 document.

[47] Admittedly, step 4 of D6 does not make it clear what is being scanned. It could be a compatibility label or a label that merely identifies the blood unit itself. While the Blood Track system diagram of D6, set out above, does indicate that a compatibility label is affixed to a blood unit after cross matching, and that scanning is performed upon removal from a fridge, the diagram steps are not linked to the process steps as set out in the related webpage “How does Blood Track work?”, which is where the step 4 scanning step is set out. Furthermore, the information that is retrieved at D6 step 4 is more consistent with the basic information that would have been included as part of an initial blood unit label attached following blood donation. Notably such information does not include patient identification information, which would have been expected to be part of a compatibility label, given the purpose of such a label.

[48] Therefore, contrary to our preliminary view in the PR letter, we are now of the view that D6 does not disclose the scanning of a compatibility label that includes information equivalent to the transfusion unit identifying code of claim 1 on file. It is more likely that what is scanned in D6 is a separate label, namely one containing a blood unit ID code such as the transfusion unit identifying code of claim 1 on file. In this respect, we agree with the Applicant’s submissions at the oral hearing and in the R-PR at page 6:

…Applicant further respectfully submits that one of ordinary skill in the art, reading D3 and D6 in combination would come to the conclusion that the scanning the blood transfusion unit in D6 involves scanning of transfusion unit identifying code (or blood unit identification code) marked on the blood unit rather than the compatibility label. [Emphasis in original]

[49] Since we are of the view that D6 does not disclose the scanning of information equivalent to the claimed transfusion unit identifying code as part of a compatibility label, we are also of the view that the comparison of such information with that scanned from a separate label containing a transfusion unit identifying code, would not have been obvious. D6 discloses no such comparison step and, as discussed above, while D3 does disclose a comparison that includes information from a compatibility label and information from a scanned unit number from a blood bag, there is no indication that the blood bag unit number is itself part of the compatibility label, so as to directly link the blood bag with the compatibility label, as is the case in claim 1 on file.

[50] As the Applicant states in the R-PR at page 7:

…the compatibility label which includes the transfusion unit identifying code as claimed functions as a redundancy mechanism to address a possible problem with improper affixation of the compatibility label on an incorrect blood unit, particularly when the compatibility label may be applied either at the blood bank laboratory or at a storage fridge. [Emphasis in original]

[51] The above points out the advantages associated with having the ability to cross-reference the information on the compatibility label with that of the transfusion unit identifying code label.

[52] We note that the Applicant has made submissions in relation to the applicability of prior art document D7 in the R-PR. However, as set out in the PR letter, it was our preliminary view that D7 is less relevant than D6 and was not further considered in the assessment of obviousness. The submissions in relation to D7 will not be considered as it is also not considered in the present assessment of obviousness.

[53] In light of the above, we conclude that the first difference identified in the PR letter, which applies to both independent claim 1 and claim 7 on file, was neither disclosed by D3 nor by D6. Nor would it have been obvious in light of D3 and D6, considered in light of the relevant CGK. This conclusion is itself sufficient to conclude that claims 1-11 on file would not have been obvious and are therefore compliant with section 28.3 of the Patent Act. However, for the sake of completeness we review below the other differences set out in the PR letter.

Generation of a request slip and the information encoded on it

[54] In the PR letter at pages 11-12 we set out our preliminary view that the use of a blood unit request slip containing encoded patient information and blood type in a blood tracking system such as that of D3 would have been obvious in view of D6 and the relevant CGK:

As noted above under step 3 and set out in the FA, D3 does not disclose the generation of a request slip for a patient, which is then compared with a compatibility label before transfusion. However, D6, which is a very similar system, albeit described in more detail, does disclose the use of an equivalent “request form”, as discussed above and confirmed by the Applicant in the R-FA at page 3. As such, it is our preliminary view that the inclusion of a request slip as part of a blood tracking system would have been obvious to the person skilled in the art.

In the R-FA at page 4, the Applicant contends that the information on the request form of D6 is scannable but that there is no suggestion that the request slip has a request slip identifying code encoding patient identifying information and the type of blood product required. This constitutes the information that forms the later portion of step e) identified as a difference above.

We agree that D6 does not explicitly disclose the inclusion of blood bag unit identification as part of the request slip. However, D6 does suggest the scanning of a request form when a blood unit is removed from a fridge in order to confirm the correct blood unit.

In our preliminary view, the inclusion of the blood type information as part of the encoded request slip information would have been a variation obvious to the person skilled in the art. In view of D6, the request slip may be scanned via a mobile device to verify patient compatibility. Further, as set out above under the relevant CGK, the use of barcodes for encoding such information was well-known. D6 specifies that in order to confirm the correct blood unit, patient information is requested from the request form. Therefore patient information is clearly part of that form. As for the blood type information, this is one of the most basic pieces of information that must be verified for blood type compatibility, and in our preliminary view, a person skilled in the art and reviewing D6, would take the step of confirming that a blood unit is the correct one as including confirmation of patient blood type. In our preliminary view, in order to confirm blood type, the request slip and the blood unit label would need to contain such information, which in D6, would be retrieved by scanning both.

[55] In the R-PR at page 10, the Applicant contends that the encoding of patient identifying information and a type of blood allows for quick verification of the correct type of blood for a patient and whether a blood unit has been allocated to a particular patient. The Applicant, at page 11 of the R-PR, particularly focusses on the encoding of blood type in a request slip as providing for both verification of a selected blood unit after selection, as well as for prompting the selection of a correct blood unit before selection, by the scanning of the request slip.

[56] The Applicant’s arguments in the R-PR generally focus on the encoding of blood type information as part of the request slip information, rather than questioning whether the request slip of D6 includes blood type information per se. This position is consistent with that taken by the Applicant at the oral hearing. At the hearing, the Applicant emphasized that there was no suggestion in D6 to encode the blood type information on the request slip.

[57] While we appreciate that there is no explicit disclosure of the encoding of information on the request slip in D6, D6 does disclose that, to further ensure that the right blood unit is taken for the right patient, an extra step can be added in the Blood Track system “to enter or scan the patient information from the request form.” As we stated in the PR letter and set out under the relevant CGK, the use of barcodes for encoding such information was well-known. In our view, in implementing the scanning step set out in D6, the use of barcodes or some other encoding method would have been obvious to the skilled person.

[58] As was the case with the discussion in relation to the first difference, we will not address here any submission in respect of prior art document D7, which was not considered to be relevant in the PR letter.

[59] In light of the above, we conclude that the inclusion of a request slip with encoded patient identification information and blood type in a blood tracking system such as that of D3 would have been obvious.

Comparing patient information on a request slip to that of a compatibility label

[60] In the PR letter at pages 12-13, we set out our preliminary view that the comparison between information on the request slip and that of the compatibility label would have been obvious:

At step 3 above, the second difference set out from the FA was the use of the request slip to verify the blood transfusion unit's identity by comparing the patient identifying information encoded in the request slip identifying code to the patient identifying information on the compatibility label on the patient allocated blood transfusion unit.

In light of the discussion above, D6 discloses the use of a blood unit request slip and, when the blood units are retrieved from storage, the scanning of the compatibility label on the blood unit as well as the information on the request slip. The information from these two sources is compared to ensure that “the blood unit is the correct one” (see webpage in D6 labelled “How does Blood Track work?” at step 5). In our preliminary view, such a step would have been obvious in light of D3 and D6 taken together with the relevant CGK.

We note that in the R-FA at page 5, the Applicant contends that D3 does not suggest the “two way comparison of the transfusion unit identifying code” or the “three-way comparison of patient identifying info” of the claims on file. However, in light of the above analysis, it is our preliminary view that such comparisons would have been obvious in light of D3 and D6 taken together with the relevant CGK.

In our preliminary view, claim 1 on file would have been obvious to the person skilled in the art in view of D3 and D6, considered in light of the relevant CGK.

[61] In light of our conclusions above in respect of D6, namely that it is not clear what is scanned at step 4 of the “How does Blood Track work?” webpage and that it is more likely that what is scanned in D6 step 4 is a label such as the separate label containing the transfusion unit identifying code of claim 1 on file, we must also revisit our previous preliminary view that step 5 in D6 represented a comparison of information on the request slip with that of the compatibility label.

[62] Since in D6 the step of scanning the request slip and comparing information to confirm a proper blood unit for a patient follows step 4, which is likely not the scanning of a compatibility label, it is now our view that D6 does not disclose or suggest the comparison of information in the request slip with that of the compatibility label, and therefore the comparison step at step (f) of claim 1 is not disclosed or suggested by either of D3 or D6 and therefore would not have been obvious.

[63] We note that no such comparison step is present in independent claim 7 on file. However, given the presence and non-obviousness of the first Sanofi step 3 difference in respect of claim 7 on file, claim 7 would not have been obviousness nonetheless.

Conclusions on obviousness

[64] In light of above, we conclude that independent claims 1 and 7 on file would not have been obvious and are therefore compliant with section 28.3 of the Patent Act. Given that dependent claims 2-6 and 8-11 depend directly or indirectly on the independent claims, they also would not have been obvious and are therefore compliant with section 28.3 of the Patent Act.

Proposed claims

[65] As indicated above, subsequent to the oral hearing for this case, the Applicant provided proposed claim set-3 in an effort to overcome the obviousness defect and address certain clarity issues discussed at the oral hearing.

[66] As we have concluded that the claims on file would not have been obvious, there is no need to assess proposed claim set-3 and we make no conclusions as to their patentability.

CONCLUSION

[67] We have determined that claims 1-11 on file would not have been obvious and are therefore compliant with section 28.3 of the Patent Act.

 

RECOMMENDATION OF THE BOARD

[68] In view of the above, the Panel is of the view that the rejection is not justified on the basis of the defect indicated in the Final Action notice and we have reasonable grounds to believe that the instant application complies with the Patent Act and the Patent Rules. We recommend that the Applicant be notified in accordance with subsection 86(10) of the Patent Rules that the rejection of the instant application is withdrawn and that the instant application has been found allowable.

Stephen MacNeil	Jeremy Garnet	Howard Sandler
Member	Member	Member

 

 

DECISION OF THE COMMISSIONER

[69] I concur with the conclusion and recommendation of the Board. In accordance with subsection 86(10) of the Patent Rules, I hereby notify the Applicant that the rejection of the instant application is withdrawn, the instant application has been found allowable and I will direct my officials to issue a Notice of Allowance in due course.

 

 

Virginie Ethier

Assistant Commissioner of Patents

Dated at Gatineau, Quebec

this 1st day of December, 2020