DETAILED ACTION
Remarks
Applicant’s amendment and response dated 12/11/2025 has been provided in response to the 9/29/2025 Office Action which rejected claims 1-8 and 10-14, wherein claims 7, 8, 10, and 11 have been amended and new claims 15 and 16 have been added. Thus, claims 1-8 and 10-16 remain pending in this application and have been fully considered by the examiner.
Applicant’s arguments, see pages 10-13, filed 12/11/2025, with respect to the rejection(s) of claim(s) 1-8 and 10-14 under 35 U.S.C. 103 have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made in view of Michel (US Patent Application Publication 2015/0254120 A1).
Claim Interpretation
3. The text of those sections of Title 35, U.S. Code not included in this action can be found in a prior Office action.
4. The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
5. This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) is/are: “first processing device… configured to”, “second processing device… configured to” and “control device” in claims 1-14. However, sufficient support for these limitations are disclosed in the specification at least at page 9, lines 32-34 “The rack 10 comprises a control device 11 which, as schematically shown in Fig. 3, comprises a processing device 13 and hence comprises electronic circuitry for controlling operation of the infusion station 1”.
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
Claim Rejections - 35 USC § 103
6. The text of those sections of Title 35, U.S. Code not included in this action can be found in a prior Office action.
7. Claims 1-8 and 10-16 are rejected under 35 U.S.C. 103 as being unpatentable over Hopermann et al. (US Patent Application Publication 2008/0097168 A1, art already of record, see IDS filed 7/8/22) in view of Borges (US Patent 9,904,765 B2, art already of record, see IDS filed 7/8/22) and Michel (US Patent Application Publication 2015/0254120 A1).
As to claim 1, Hopermann teaches a system for administering a medical fluid to a patient (see Fig.1 an associated text), comprising: an infusion station (e.g. medical workstation 1) comprising a slot (e.g. communication line 5 connection) for receiving an infusion device (e.g. therapy module 3, see e.g. [0006] and [0032]- a medical workstation according to the invention has a central control and display unit 1, which has at least one display area 9 for displaying alarms, warnings and instructions. The control and display unit 1 is connected to a patient monitor module 2 via a communications line 5. The control and display unit 1 is preferably connected to the patient monitor module 2 via a central network element 4 (switch/hub), which makes possible a star-shaped network topology. The medical workstation has an interface for connecting a therapy module 3, which interface is readily accessible to the user. The interface for connecting the therapy module 3 is preferably located at the central network element 4),
a first processing device associated with the infusion station (e.g. microprocessor of the control and display unit 1, see e.g. [0032]- The control and display unit 1 has a microprocessor), and configured to execute a first software application (e.g. operating program) being associated with a first version identifier (See e.g.[0015]- The control and display unit has an operating program) and [0033]- the control and display unit 1 sends its program version to the therapy module 3), and
a second processing device associated with the infusion station (e.g. microprocessor of the therapy module, see e.g. [0032]- The therapy module 3 has at least one microprocessor) and configured to execute a second software application being associated with a second version identifier (See e.g. [0033]- After the therapy module 3 has been connected, this therapy module 3 sends its program version to the control and display unit 1),
and at least one of the first processing device and the second processing device is configured to perform a compatibility check of the first software application with the second software application based on the first version identifier and the second version identifier (see e.g. [0034]- After the program version has been sent, the control and display unit 1 checks the compatibility of its program version with that of the therapy module 3. It is optionally also possible that the therapy module 3 checks the compatibility of its program version with that of the control and display unit 1 and sends the result to the control and display unit 1).
Hopermann does not specifically teach that the infusion station comprises a rack defining a multiplicity of slots for receiving a multiplicity of infusion devices.
In an analogous art of operating medical devices, however, Borges teaches a system for administering a medical fluid to a patient (See Fig.1 and associated text, e.g. col. 2 line 63-col 3 line 2: A wide variety of medical devices and medical device modules can be used in conjunction with the medical device controller. For example, the system can be used with infusion pumps such as syringe pumps, patient controlled infusion pumps (e.g., patient-controlled analgesia (PCA) system), large volume infusion pumps, peristaltic pumps, and the like), comprising: an infusion station (e.g. medical device system 110) comprising a rack (e.g. backplane 120) defining a multiplicity of slots (e.g. mounting seats 112) for receiving a multiplicity of infusion devices (e.g. medical device modules 150, see e.g. col.4 lines 45-60: The system 110 comprises a backplane 120 that can be mounted on a pole 105. The backplane 120 can mechanically couple to and secure one or more medical device modules 150 (also referred to herein as a medical device) along each of a series of pre-defined mounting seats 112. In some variations, each of the mounting seats 112 are uniform in size and spacing, while in other variations different sizing and/or spacing can be used to accommodate medical device modules 150 having different exterior dimensions. In addition, the mounting seats 112 can be arranged along a single axis (e.g., a vertical axis as illustrated, etc.) or they can be arranged along two or more axes. The mounting seats 112 can each have one or more mechanical elements to detachably affix the medical device modules 150 to the backplane 120), a first processing device associated with the infusion station (e.g. processor of medical device 440E connected to the medical device system 110) and configured to execute a first software application being associated with a first version identifier (See Fig.4 and associated text, e.g. col.13 lines 40-54: Medical devices 440A-F/modules 150, and/or medical device system 110 can contain one or more processors and at least one memory. Executable program code (e.g. software or executable code) is stored in the at least one memory where the executable program code causes the devices 440A-F, 150, 110 to perform operations required for patient care; each of the devices 440A-F, 150, 110 may require a current version of software stored in the at least one memory and may also require a current version of configuration information), and a second processing device associated with the infusion station (e.g. processor of medical device 440F connected to the medical device system 110) and configured to execute a second software application being associated with a second version identifier (See Fig.4 and associated text, e.g. col.13 lines 40-46: Medical devices 440A-F/modules 150, and/or medical device system 110 can contain one or more processors and at least one memory. Executable program code (e.g. software or executable code) is stored in the at least one memory where the executable program code causes the devices 440A-F, 150, 110 to perform operations required for patient care; each of the devices 440A-F, 150, 110 may require a current version of software stored in the at least one memory and may also require a current version of configuration information).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to have modified the method/system of Hopermann to incorporate/implement the limitations as taught by Borges in order to provide a more efficient method/system of coordinating the operation of multiple medical devices to ensure proper performance.
Although Hopermann in view of Borges teaches perform a compatibility check of the first software application with the second software application based on the first version identifier, the second version identifier (See Hopermann: e.g. [0033] and [0034]), Hopermann in view of Borges does not specifically teach wherein the first processing device is configured to store a first data structure comprising first compatibility information and the second processing device is configured to store a second data structure comprising second compatibility information, and at least one of the first processing device and the second processing device is configured to perform both a compatibility check of the first software application with the second application and a compatibility check of the second software application with the first software application based on the first version identifier, the second version identifier, the first data structure and the second data structure.
In an analogous art of communicating devices, however, Michel teaches wherein a first processing device (e.g. device 12A) is configured to store a first data structure comprising first compatibility information (see e.g. [0046]- each memory 18A, 18B, 18C, 18D comprises a compatibility table 22A, 22B, 22C, 22D for defining compatibility with said other complementary device(s), each compatibility table 22A, 22B, 22C, 22D comprising at least one minimum required version number for each of said other complementary device(s)) and [0047]- Each memory 18A, 18B, 18C, 18D further comprises a version number, not shown, for each hardware or software function integrated into the electronic device 12A, 12B, 12C, 12D that comprises said memory 18A, 18B, 18C, 18D) and the second processing device (e.g. device 12B) is configured to store a second data structure comprising second compatibility information (see e.g. [0046]- each memory 18A, 18B, 18C, 18D comprises a compatibility table 22A, 22B, 22C, 22D for defining compatibility with said other complementary device(s), each compatibility table 22A, 22B, 22C, 22D comprising at least one minimum required version number for each of said other complementary device(s) and [0047]- Each memory 18A, 18B, 18C, 18D further comprises a version number, not shown, for each hardware or software function integrated into the electronic device 12A, 12B, 12C, 12D that comprises said memory 18A, 18B, 18C, 18D) and at least one of the first processing device and the second processing device is configured to perform both a compatibility check of the first software application with the second application and a compatibility check of the second software application with the first application based on a first version, a second version, the first data structure and the second data structure (see e.g. [0053]- Each compatibility table 22A, 22B, 22C, 22D comprises, for the associated device 12A, 12B, 12C, 12D and in whose memory it is stored, at least one minimum version number required for each of said other complementary device(s) of that associated device, [0057]-When an electronic device 12A, 12B, 12C, 12D comprises at least one software function, the corresponding compatibility table 22A, 22B, 22C, 22D comprises, for each software function, a minimum version number required for each of said other complementary device(s) of the electronic device and for the software function in question, and [0101]- each device, i.e., the first device 12A, the second device 12B and the fourth device 12D, comprises its own verification module 24A, 24B, 24D and is adapted for performing its own compatibility verification with the other complementary devices of the system 10. The first device 12A then uses its compatibility table 22A to verify its compatibility with the second device 12B (arrow F.sub.AB) on the one hand, and with the fourth device 12D (arrow F.sub.AD) on the other hand. Similarly, the second device 12B then uses its compatibility table 22B to verify its compatibility with the first device 12A (arrow F.sub.BA) on the one hand, and with the fourth device 12D (arrow F.sub.BD) on the other hand. Lastly, the fourth device 12D then uses its compatibility table 22D to verify its compatibility with the first device 12A (arrow F.sub.DA) on the one hand, and with the second device 12B (arrow F.sub.DB) on the other hand and [0103]- Each device 12A, 12B, 12C, 12D is in fact preferably adapted for storing the results of the compatibility verifications in its memory 18A, 18B, 18C, 18D, whether those verifications have been done directly by said device or indirectly by another device via the aforementioned delegating mechanism. In other words, each device 12A, 12B, 12C, 12D is preferably adapted for storing any unitary deviation indicator it may have in its memory 18A, 18B, 18C, 18D).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to have modified the method/system of Hopermann in view of Borges to incorporate/implement the limitations as taught by Michel in order to provide a more efficient method/system of determining compatibility of one or more devices that would ensure proper performance.
As to claim 2, Hopermann also teaches wherein the infusion station comprises a control device comprising said first processing device (See e.g. [0032]- The control and display unit 1 has a microprocessor).
As to claim 3, Borges further teaches at least one infusion device to be attached to one of said multiplicity of slots of the rack (e.g. medical device 150), the at least one infusion device comprising said second processing device (See Borges: Fig.4 and associated text, e.g. col.13 lines 40-54: Medical devices 440A-F/modules 150, and/or medical device system 110 can contain one or more processors and at least one memory. Executable program code (e.g. software or executable code) is stored in the at least one memory where the executable program code causes the devices 440A-F, 150, 110 to perform operations required for patient care).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to have modified the method/system of Hopermann to incorporate/implement the limitations as taught by Borges in order to provide a more efficient method/system of coordinating the operation of multiple medical devices to ensure proper performance.
As to claim 4, Borges further teaches a server external to the infusion station and comprising said first processing device (see Fig.4, 410 and associated text, e.g. col.12 lines 18-20: Client 420 and servers 410, 415 are generally remote from each other and typically interact through the communications network 405 and col.13 lines 18-22: One or more attributes of the medical devices 440 can be locally controlled by a clinician, controlled via a clinician via the network 405, and/or they can be controlled by one or more of a server 410).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to have modified the method/system of Hopermann to incorporate/implement the limitations as taught by Borges in order to provide a more efficient method/system of coordinating the operation of multiple medical devices to ensure proper performance.
As to claim 5, Hopermann also teaches wherein the infusion station comprises a control device comprising said second processing device, see e.g. [0032]- The control and display unit 1 has a microprocessor).
As to claim 6, Borges further teaches at least one infusion device to be attached to one of said multiplicity of slots of the rack, the at least one infusion device comprising said second processing device (See Borges: Fig.4 and associated text, e.g. col.13 lines 40-54: Medical devices 440A-F/modules 150, and/or medical device system 110 can contain one or more processors and at least one memory. Executable program code (e.g. software or executable code) is stored in the at least one memory where the executable program code causes the devices 440A-F, 150, 110 to perform operations required for patient care).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to have modified the method/system of Hopermann to incorporate/implement the limitations as taught by Borges in order to provide a more efficient method/system of coordinating the operation of multiple medical devices to ensure proper performance.
As to claim 7, Hopermann teaches wherein the second processing device is configured, on an occasion of attaching the at least one infusion device to transfer said second version identifier to the first processing device to enable the first processing device to perform a compatibility check (see e.g. [0034]- After the program version has been sent, the control and display unit 1 checks the compatibility of its program version with that of the therapy module 3. It is optionally also possible that the therapy module 3 checks the compatibility of its program version with that of the control and display unit 1 and sends the result to the control and display unit 1), but does not specifically teach one of the multiplicity of slots of the rack. In an analogous art of operating medical devices, Borges teaches one of the multiplicity of slots of the rack (see e.g. col.4 lines 45-60: The system 110 comprises a backplane 120 that can be mounted on a pole 105. The backplane 120 can mechanically couple to and secure one or more medical device modules 150 (also referred to herein as a medical device) along each of a series of pre-defined mounting seats 112. In some variations, each of the mounting seats 112 are uniform in size and spacing, while in other variations different sizing and/or spacing can be used to accommodate medical device modules 150 having different exterior dimensions. In addition, the mounting seats 112 can be arranged along a single axis (e.g., a vertical axis as illustrated, etc.) or they can be arranged along two or more axes. The mounting seats 112 can each have one or more mechanical elements to detachably affix the medical device modules 150 to the backplane 120).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to have modified the method/system of Hopermann to incorporate/implement the limitations as taught by Borges in order to provide a more efficient method/system of coordinating the operation of multiple medical devices to ensure proper performance.
Hopermann in view of Borges does not specifically teach performing both the compatibility check of the first software application with the second software application and the compatibility check of the second software application with the first software application.
In an analogous art of communicating devices, however, Michel teaches a first processing device to perform both a compatibility check of the first software application with the second application and the compatibility check of the second software application with the first software application (see e.g. [0053]- Each compatibility table 22A, 22B, 22C, 22D comprises, for the associated device 12A, 12B, 12C, 12D and in whose memory it is stored, at least one minimum version number required for each of said other complementary device(s) of that associated device, [0057]-When an electronic device 12A, 12B, 12C, 12D comprises at least one software function, the corresponding compatibility table 22A, 22B, 22C, 22D comprises, for each software function, a minimum version number required for each of said other complementary device(s) of the electronic device and for the software function in question, and [0101]- each device, i.e., the first device 12A, the second device 12B and the fourth device 12D, comprises its own verification module 24A, 24B, 24D and is adapted for performing its own compatibility verification with the other complementary devices of the system 10. The first device 12A then uses its compatibility table 22A to verify its compatibility with the second device 12B (arrow F.sub.AB) on the one hand, and with the fourth device 12D (arrow F.sub.AD) on the other hand. Similarly, the second device 12B then uses its compatibility table 22B to verify its compatibility with the first device 12A (arrow F.sub.BA) on the one hand, and with the fourth device 12D (arrow F.sub.BD) on the other hand. Lastly, the fourth device 12D then uses its compatibility table 22D to verify its compatibility with the first device 12A (arrow F.sub.DA) on the one hand, and with the second device 12B (arrow F.sub.DB) on the other hand and [0103]- Each device 12A, 12B, 12C, 12D is in fact preferably adapted for storing the results of the compatibility verifications in its memory 18A, 18B, 18C, 18D, whether those verifications have been done directly by said device or indirectly by another device via the aforementioned delegating mechanism. In other words, each device 12A, 12B, 12C, 12D is preferably adapted for storing any unitary deviation indicator it may have in its memory 18A, 18B, 18C, 18D).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to have modified the method/system of Hopermann in view of Borges to incorporate/implement the limitations as taught by Michel in order to provide a more efficient method/system of determining compatibility of one or more devices that would ensure proper performance.
As to claim 8, Hopermann in view of Borges teaches wherein said at least one of the first processing device and the second processing device is configured to examine, for performing a compatibility check (See e.g. Hopermann: [0034]), but does not specifically teach performing the compatibility check of the first software application with the second software application and the compatibility check of the second software application with the first software application, whether the first version identifier and/or the second version identifier is identified in the data structure. In an analogous art of communicating devices, however, Michel teaches performing the compatibility check of the first software application with the second software application and the compatibility check of the second software application with the first software application, whether the first version identifier and/or the second version identifier is identified in the data structure (see e.g. [0053]- Each compatibility table 22A, 22B, 22C, 22D comprises, for the associated device 12A, 12B, 12C, 12D and in whose memory it is stored, at least one minimum version number required for each of said other complementary device(s) of that associated device, [0057]-When an electronic device 12A, 12B, 12C, 12D comprises at least one software function, the corresponding compatibility table 22A, 22B, 22C, 22D comprises, for each software function, a minimum version number required for each of said other complementary device(s) of the electronic device and for the software function in question, and [0101]- each device, i.e., the first device 12A, the second device 12B and the fourth device 12D, comprises its own verification module 24A, 24B, 24D and is adapted for performing its own compatibility verification with the other complementary devices of the system 10. The first device 12A then uses its compatibility table 22A to verify its compatibility with the second device 12B (arrow F.sub.AB) on the one hand, and with the fourth device 12D (arrow F.sub.AD) on the other hand. Similarly, the second device 12B then uses its compatibility table 22B to verify its compatibility with the first device 12A (arrow F.sub.BA) on the one hand, and with the fourth device 12D (arrow F.sub.BD) on the other hand. Lastly, the fourth device 12D then uses its compatibility table 22D to verify its compatibility with the first device 12A (arrow F.sub.DA) on the one hand, and with the second device 12B (arrow F.sub.DB) on the other hand and [0103]- Each device 12A, 12B, 12C, 12D is in fact preferably adapted for storing the results of the compatibility verifications in its memory 18A, 18B, 18C, 18D, whether those verifications have been done directly by said device or indirectly by another device via the aforementioned delegating mechanism. In other words, each device 12A, 12B, 12C, 12D is preferably adapted for storing any unitary deviation indicator it may have in its memory 18A, 18B, 18C, 18D).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to have modified the method/system of Hopermann in view of Borges to incorporate/implement the limitations as taught by Michel in order to provide a more efficient method/system of determining compatibility of one or more devices that would ensure proper performance.
As to claim 10, Michel further teaches wherein the first compatibility information comprises a first amount of identifier information, wherein the first amount of identifier information is a first list of software versions which are compatible or not compatible with the first software application (see e.g. [0046]- each memory 18A, 18B, 18C, 18D comprises a compatibility table 22A, 22B, 22C, 22D for defining compatibility with said other complementary device(s), each compatibility table 22A, 22B, 22C, 22D comprising at least one minimum required version number for each of said other complementary device(s) and [0047]- Each memory 18A, 18B, 18C, 18D further comprises a version number, not shown, for each hardware or software function integrated into the electronic device 12A, 12B, 12C, 12D that comprises said memory 18A, 18B, 18C, 18D).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to have modified the method/system of Hopermann in view of Borges to incorporate/implement the limitations as taught by Michel in order to provide a more efficient method/system of determining compatibility of more or more devices that would ensure proper performance.
As to claim 11, Michel further teaches wherein the second compatibility information comprises a second amount of identifier information, wherein the second amount of identifier information is a second list of software versions which are compatible or not compatible with the second software application (see e.g. [0046]- each memory 18A, 18B, 18C, 18D comprises a compatibility table 22A, 22B, 22C, 22D for defining compatibility with said other complementary device(s), each compatibility table 22A, 22B, 22C, 22D comprising at least one minimum required version number for each of said other complementary device(s) and [0047]- Each memory 18A, 18B, 18C, 18D further comprises a version number, not shown, for each hardware or software function integrated into the electronic device 12A, 12B, 12C, 12D that comprises said memory 18A, 18B, 18C, 18D).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to have modified the method/system of Hopermann in view of Borges to incorporate/implement the limitations as taught by Michel in order to provide a more efficient method/system of determining compatibility of more or more devices that would ensure proper performance.
As to claim 12, Michel further teaches wherein said at least one of the first processing device and the second processing device is configured to examine, for performing the compatibility check, whether the first version identifier is identified in the second data structure and/or the second version identifier is identified in the first data structure (see e.g. [0053]- Each compatibility table 22A, 22B, 22C, 22D comprises, for the associated device 12A, 12B, 12C, 12D and in whose memory it is stored, at least one minimum version number required for each of said other complementary device(s) of that associated device, [0057]-When an electronic device 12A, 12B, 12C, 12D comprises at least one software function, the corresponding compatibility table 22A, 22B, 22C, 22D comprises, for each software function, a minimum version number required for each of said other complementary device(s) of the electronic device and for the software function in question, and [0101]- each device, i.e., the first device 12A, the second device 12B and the fourth device 12D, comprises its own verification module 24A, 24B, 24D and is adapted for performing its own compatibility verification with the other complementary devices of the system 10. The first device 12A then uses its compatibility table 22A to verify its compatibility with the second device 12B (arrow F.sub.AB) on the one hand, and with the fourth device 12D (arrow F.sub.AD) on the other hand. Similarly, the second device 12B then uses its compatibility table 22B to verify its compatibility with the first device 12A (arrow F.sub.BA) on the one hand, and with the fourth device 12D (arrow F.sub.BD) on the other hand. Lastly, the fourth device 12D then uses its compatibility table 22D to verify its compatibility with the first device 12A (arrow F.sub.DA) on the one hand, and with the second device 12B (arrow F.sub.DB) on the other hand and [0103]- Each device 12A, 12B, 12C, 12D is in fact preferably adapted for storing the results of the compatibility verifications in its memory 18A, 18B, 18C, 18D, whether those verifications have been done directly by said device or indirectly by another device via the aforementioned delegating mechanism. In other words, each device 12A, 12B, 12C, 12D is preferably adapted for storing any unitary deviation indicator it may have in its memory 18A, 18B, 18C, 18D).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to have modified the method/system of Hopermann in view of Borges to incorporate/implement the limitations as taught by Michel in order to provide a more efficient method/system of determining compatibility of more or more devices that would ensure proper performance.
As to claim 13, Michel further wherein said at least one of the first processing device and the second processing device is configured to enable an interworking of the first software application and the second software application if and only if the first version identifier is not identified in the second data structure and the second version identifier is not identified in the first data structure as being not compatible (See e.g. [0087]- the verification module 24A, 24B, 24D determines whether one or more incompatibilities have been detected, i.e., whether one or more recovered version numbers are strictly lower, within the meaning of the ordering law for the version numbering, than the minimum required version numbers contained in the corresponding compatibility table 22A, 22B, 22D and [0089]- If, on the contrary, at least one incompatibility is detected, then the cause(s) having caused that version deviation leading to an incompatibility are managed during step 225 and a deviation level, i.e., a deviation indicator, is generated; Managing the causes of the version deviation for example also leads, as long as the update has not been done, to partially or completely deactivating each function affected by the detected incompatibility or incompatibilities, as well as reporting each incompatibility to the user).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to have modified the method/system of Hopermann in view of Borges to incorporate/implement the limitations as taught by Michel in order to provide a more efficient method/system of determining compatibility of more or more devices that would ensure proper performance.
As to claim 14, the limitations of claim 14 are substantially similar to the limitations of claim 1 and therefore it is rejected for the reason stated above.
As to claim 15, the limitations of claim 15 are substantially similar to the limitations of claim 10 and therefore it is rejected for the reason stated above.
As to claim 16, the limitations of claim 16 are substantially similar to the limitations of claim 11 and therefore it is rejected for the reason stated above.
Conclusion
8. Any inquiry concerning this communication or earlier communications from the examiner should be directed to CHENECA SMITH whose telephone number is (571)270-1651. The examiner can normally be reached Mon-Fri 8:00AM-4:30PM EST.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Hyung S Sough can be reached on 571-272-6799. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/CHENECA SMITH/Examiner, Art Unit 2192
/S. Sough/SPE, Art Unit 2192