DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Status of the Claims
The office action is in response to the claim amendments and remarks filed on July 20, 2026 for the application filed April 17, 2024. Claims 1 and 10 have been amended, claims 2-3 have been cancelled and claim 17 has been newly added. Claims 1 and 4-17 are currently pending and have been examined.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1, 7-15 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Rajan et al. (U.S. Pub. No. 2016/0029420) in view of Newham et al. (U.S. Pub. No. 2017/0259072) and Contino et al. (U.S. Pub. No. 2012/0023293).
Regarding claim 1, Rajan discloses a transfer device for transferring at least one file stored on a Paragraph [0046], The wireless communication hub device may collect data provided by the various electronic medical and fitness devices in the home, package the data into suitable packets for communication via wireless and Internet communication links, and send the data packets back to the central server.), said transfer device comprising:
at least one input interface configured to receive said at least one file from said Abstract, A wireless communication hub device may include a processor and wireless communication transceivers configured to connect to cellular and/or WiFi networks to access a remote server, and wired and/or wireless local networks for connecting to electronic medical or fitness devices. Paragraph [0044], the wireless communication hub device is configured to connect to wireless wide area networks (WWAN) (e.g., cellular telephone) and/or WiFi communication networks to provide one side of a communication link, and to medical, fitness and personal sensors via wireless (e.g., BlueTooth®) and wired (e.g., USB) local communication links to provide the other side of the communication link. Thus, the wireless communication hub device can serve as the connection gateway between a variety of different types of medical, fitness and personal sensor devices which can only communicate locally, and remote servers, remote facilities, and data server/storage systems which can use the data of such devices but are only coupled to the Internet.),
a memory comprising a memory space configured to receive said at least one file from said at least one input interface (Paragraph [0082], The wireless communication hub device 112 may be configured in a case or housing 300 and may include a programmable processor 301 that is coupled to internal memory 302. Paragraph [0094], the wireless communication hub device system 400 may include memory and store-and-forward logic 412 for receiving and storing data from electronic medical and fitness devices.),
at least one processor configured to (Paragraph [0082], The wireless communication hub device 112 may be configured in a case or housing 300 and may include a programmable processor 301 that is coupled to internal memory 302. Paragraph [0086], The processor 301 within a wireless communication hub device 112 may be configured with processor-executable instructions (which may be stored in memory 302) to enable the processes and communications of the various embodiments described herein.):
detect when a connection is established between said transfer device and said Paragraph [0145], electronic medical and fitness device 102 a and the wireless communication hub device 112 may establish a first communication link with each other.),
detect when said at least one file is written into said memory space after said connection is established (Paragraph [0145], the wireless communication hub device 112 may receive the electronic medical and fitness device data. At block 2410 the wireless communication hub device 112 may store the received electronic medical and fitness device data in a memory resident on the wireless communication hub device 112. Paragraph [0094], the wireless communication hub device system 400 may include memory and store-and-forward logic 412 for receiving and storing data from electronic medical and fitness devices and relaying that data at a later time to a destination computer. Router, server and store-and-forward processes and logic are well-known in the computer arts.),
at least one output interface configured to send said at least one file to said remote platform (Abstract, A wireless communication hub device may include a processor and wireless communication transceivers configured to connect to cellular and/or WiFi networks to access a remote server, and wired and/or wireless local networks for connecting to electronic medical or fitness devices. Paragraph [0044], the wireless communication hub device is configured to connect to wireless wide area networks (WWAN) (e.g., cellular telephone) and/or WiFi communication networks to provide one side of a communication link, and to medical, fitness and personal sensors via wireless (e.g., BlueTooth®) and wired (e.g., USB) local communication links to provide the other side of the communication link. Thus, the wireless communication hub device can serve as the connection gateway between a variety of different types of medical, fitness and personal sensor devices which can only communicate locally, and remote servers, remote facilities, and data server/storage systems which can use the data of such devices but are only coupled to the Internet.), wherein said at least one processor is further configured to transmit said at least one file, after detection that said at least one file has been written into said memory space, from said memory space to said remote platform via said at least one output interface (Paragraph [0146], At block 2506 the wireless communication hub device 112 may transmit the electronic medical and fitness device data to the service platform server 140, and at block 2508 the service platform server 140 may receive the electronic medical and fitness data. Paragraph [0094], the wireless communication hub device system 400 may include memory and store-and-forward logic 412 for receiving and storing data from electronic medical and fitness devices and relaying that data at a later time to a destination computer. Router, server and store-and-forward processes and logic are well-known in the computer arts.),
wherein said transfer device is configured to emulate:
a behavior of a Universal Serial Bus (USB) Paragraph [0050], provide a “universal” hub to handle health-sensitive data from any of a variety of electronic medical and fitness devices. enables manufacturers of various electronic medical and fitness devices to be able to pair up with the hub without significant changes to their devices, thus enabling them to avoid the need to be concerned with communication protocols and data encryption. This enables the wireless communication hub device to function as a data-in/data-out device, with its only function being to collect, package and faithfully transfer data to the service platform server. Paragraph [0052], A wireless communication hub device may be configured to use software interface models that mirror the types of devices that can be connected to computers via USB (Universal serial bus) or FireWire ports.); or
a behavior Paragraph [0050], provide a “universal” hub to handle health-sensitive data from any of a variety of electronic medical and fitness devices. enables manufacturers of various electronic medical and fitness devices to be able to pair up with the hub without significant changes to their devices, thus enabling them to avoid the need to be concerned with communication protocols and data encryption. This enables the wireless communication hub device to function as a data-in/data-out device, with its only function being to collect, package and faithfully transfer data to the service platform server. Paragraph [0052], A wireless communication hub device may be configured to use software interface models that mirror the types of devices that can be connected to computers via USB (Universal serial bus) or FireWire ports.), and
Rajan does not appear to explicitly disclose that the device is a programming device or that the device is configured for interfacing with a medical device intended to be implanted in a patient’s body for reviewing and setting adjustments of said medical device and being configured to generate said at least one file from at least one data received from the medical device, the programming device comprising at least one of a USB port or an Ethernet port.
Newham teaches that it was old and well known in the art of medical device communication at the time of the filing to provide a transfer device for transferring at least one file stored on a programming device to a remote platform, said programming device configured for interfacing with a medical device intended to be implanted in a patient’s body for reviewing and setting adjustments of said medical device and being configured to generate said at least one file from at least one data received from the medical device, the programming device comprising at least one of a USB port or an Ethernet port (Newham, paragraph [0031], The system 100 includes an implant device 200 and a remote device 300. As used herein, the implant device may be referred to as an implantable device or implantable medical device. The remote device 300 may be configured to wirelessly communicate with the implant device via a secure communication pathway 50. The remote device 300 can be configured to transmit wireless signals via communication pathway 50 and the implant device 200 can be configured to receive the wireless signals. The remote device 300 can be configured to facilitate wireless data transfer between the implant device 200 and the remote device 300. In some implementations, the remote device 300 may include but is not limited to an interrogator device or interrogator medical device, an external medical device, a programming device. Paragraph [0044], the remote device 300 may include the carrier board 375 and the computing device 325. Separating the carrier board 375 from the computing device 325 can separate the functionality of communicating with the implant device 200, which can involve safety critical features, from the functionality of communicating with non-implanted devices like smartphones, wireless communication hubs, and cloud-based database systems, which do not involve safety critical features. In some implementations, the computing device 325 of the remote device 300 can include the communications component 350 configured to communicate with non-implanted devices in any appropriate frequency bands, such as Bluetooth or Wi-Fi or cellular. In some implementations, the communications component 350 is configured to communicate across a wired interface, such as Universal Serial Bus (USB) or Ethernet. Paragraph [0054], In some implementations, the communications component 350 can communicate data received from the implant device 200 to a database system, such as a cloud-based database system, over a wired or wireless interface. Paragraph [0058], The RF unit 378 can include one or more of a receiver, transmitter, and two-way transceiver to wirelessly communicate with another device, such as the implant device 200. In some implementations, the RF unit 378 in the carrier board 375 may be configured to transmit programming instructions for configuring the implant device 200, and may be configured to receive data (e.g., compliance data) from the implant device 200. Paragraph [0092], The physiological data of the patient may be collected and analyzed by the implant device. In some implementations, the physiological data may be calculated, estimated, processed, and/or analyzed by one or more processors of the implant device. In some implementations, the raw physiological data or the analyzed physiological data may be stored in the memory of the implant device. Paragraph [0043], In the implementation in FIG. 3, the remote device 300 includes a clock 320, a control system 330, a memory 340, a communications component 350, and a power supply 360. The control system 330 may be capable of performing some or all of the methods described herein.) to provide secure communications between implant devices and outside device (Newham, paragraph [0005]).
Therefore, it would have been obvious to one of ordinary skill in the art of medical device communication at the time of the filing to modify the device of Rajan such that the device is a programming device configured for interfacing with a medical device intended to be implanted in a patient’s body for reviewing and setting adjustments of said medical device and being configured to generate said at least one file from at least one data received from the medical device, the programming device comprising at least one of a USB port or an Ethernet port, as taught by Newham, in order to provide secure communications between implant devices and outside devices.
Rajan further discloses that the wireless communication hub device system 400 may include memory and store-and-forward logic 412 for receiving and storing data from electronic medical and fitness devices and relaying that data at a later time to a destination computer and that router, server and store-and-forward processes and logic are well-known in the computer arts (Paragraph [0094]), but does not appear to explicitly disclose wherein said transfer device is configured to emulate: a behavior of a Universal Serial Bus (USB) storage device or a behavior of a printer; or wherein the memory space of the transfer device is a shared memory space and the processor is configured to share the shared memory space with the programming device.
Contino teaches that it was old and well known in the art of wireless communication devices at the time of the filing to provide a transfer device configured to emulate a behavior of a Universal Serial Bus (USB) storage device (Contino, paragraph [0020], wireless device 112 may be connected to host device 110 via a USB port. To successfully communicate with each other, host device 110 and wireless device 112 perform a USB enumeration process. Paragraph [0024], As a result of wireless device 112 informing host device 110 that wireless device 112 should be configured and controlled as a mass storage device, host device 110 may treat wireless device 112 as a locally attached mass storage device. For example, host device 110 may enumerate wireless device 112 as a USB flash drive. That may mean that host device 110 would use portions of its operating system software, such as device drivers, intended to be used with a USB flash drive to configure, control, and communicate with wireless device 112. Host device 110 may use these portions of its operating system software even though wireless devices in general would normally be enumerated as communication devices. Paragraph [0026], Wireless device 112 may emulate a mass storage device by also using the corresponding communication and configuration protocols to communicate with host device 110. Also see paragraphs [0025] and [0048]-[0049].).
Therefore, it would have been obvious to one of ordinary skill in the art of wireless communication devices at the time of the filing to modify the wireless communication hub device of Rajan to emulate a behavior of a Universal Serial Bus (USB) storage device, as taught by Contino, such that the memory of the communication hub with store and forward logic acts as a shared memory space and the processor is configured to share the shared memory space with the programming device, in order to allows wireless device to be treated as locally attached mass storage by non-driver parts of the operating system and applications. Furthermore, this is merely a simple substitution of the known use software interface models that mirror the types of devices that can be connected to computers via USB of Rajan for the use of emulating the behavior of a Universal Serial Bus (USB) storage device Contino to obtain the predictable result of allowing a wireless device to be treated as locally attached mass storage by non-driver parts of the operating system and applications.
Regarding claim 7, Rajan as modified by Newham further discloses wherein said transfer device is configured to establish a connection with multiple programming devices (Paragraph [0082], the wireless communication hub device 112 may include multiple USB ports 310, FireWire ports 311, and Ethernet sockets 312 to enable connecting a number of electronic medical and fitness devices via data cables.).
Regarding claim 8, Rajan as modified by Newham further discloses wherein said at least one processor is further configured to select one programming device among the multiple programming devices from which said at least one input interface is configured to receive said at least one file (Paragraph [0073], If the service platform server 140 does not have the requested data in memory, it may transmit a data request message 728 to the wireless communication hub device 112. The wireless communication hub device 112 relays the data request message 730 to the selected electronic medical and fitness device 102. Data generated in response to the request may be transmitted from the electronic medical and fitness device 102 to the wireless communication hub device 112 via the established cable or wireless communication link, message 732. Also see paragraphs [0017] and ).
Regarding claim 9, Rajan further discloses wherein said at least one processor is further configured, before transmission of said at least one file to said remote platform, to send a transmission request to a transmitter service of said remote platform (Paragraph [0153], the wireless communication hub device 112 may send a device authentication request to the service platform server 140. Paragraph [0146], At blocks 2502 and 2504 the wireless communication hub device 112 and may the service platform server 140 may establish a wireless communication link with each other.) and to notify a transmission success to said transmitter service (Paragraph [0147], At block 2602 the wireless communication hub device 112 may maintain a transmittal log. In an embodiment, the transmittal log may be a log of all transmissions sent from the wireless communication hub device 112. At block 2608 the wireless communication hub device 112 may transmit the data traffic log(s) (i.e., the transmittal log and/or the receipt log) to the service platform server 140.).
Regarding claim 10, Rajan as modified by Rajan and Contino further discloses a computer-implemented method for transferring at least one file from a programming device to a remote platform, said programming device being configured to generate said at least one file from at least one data received from a medical device implanted in a patients body, said method being implemented with the transfer device according to claim 1 (Paragraph [0116], the wireless communication hub device 112 may encapsulate the device data within IP packets so that the data can be tunneled through the Internet for processing by the service platform server 140 using an appropriate driver software. See claim 1 above for the teaching of the programming device being configured to generate said at least one file from at least one data received from a medical device implanted in a patients body by Newham, modifying the device of Rajan.), said method comprising the steps of:
establishing a connection between said transfer device and said programming device (Paragraph [0145], electronic medical and fitness device 102 a and the wireless communication hub device 112 may establish a first communication link with each other. See claim 1 above for the teaching of the programming device by Newham, modifying the device of Rajan.),
detecting when said at least one file is written into said memory space (Paragraph [0145], the wireless communication hub device 112 may receive the electronic medical and fitness device data. At block 2410 the wireless communication hub device 112 may store the received electronic medical and fitness device data in a memory resident on the wireless communication hub device 112.),
transmitting said at least one file from said memory space to said remote platform (Paragraph [0146], At block 2506 the wireless communication hub device 112 may transmit the electronic medical and fitness device data to the service platform server 140, and at block 2508 the service platform server 140 may receive the electronic medical and fitness data.).
Regarding claim 11, Rajan further discloses notifying to a user success or failure of said transmission (Paragraph [0138], The server 142, 144 receiving the data may then process or use the data for other purposes, such as transmitting a notification message to the user's personal computer 138 via the Internet 114, message 960.).
Regarding claim 12, Rajan further discloses storing said at least one file into a storage space of said remote platform (Paragraph [0146], At block 2510 the service platform server 140 may store the electronic medical and fitness device data.).
Regarding claim 13, Rajan further discloses processing, by a file parser service of said remote platform, said at least one data comprised in said at least one file (Paragraph [0119], The service platform server 140 may receive message packets from the wireless communication hub device 112, unpack the electronic medical or fitness device data from the tunneling IP packets, and use the appropriate driver software to process the received electronic medical or fitness device data, step 614. Also see paragraph [0074], the encapsulating IP packets from the wireless communication hub device 112 may be received by the service platform server 140, which unpacks the packets so the medical or fitness device 102 (e.g., a blood pressure (“BP”) sensor) data may be processed by the driver software module appropriate for the medical or fitness device 102 resident on the service platform server 140 and the translated data may be stored on the service platform server 140. In this manner the processing of the electronic medical or fitness device data in the service platform server 140 using a driver appropriate for the electronic medical or fitness device 102 may enable storage of translated data that may be in a useful format to various data users.).
Regarding claim 14, Rajan further discloses wherein said processing comprises extracting at least one data of interest from said at least one file and automatically generating a medical report based on at least said data of interest (Paragraph [0074], the encapsulating IP packets from the wireless communication hub device 112 may be received by the service platform server 140, which unpacks the packets so the medical or fitness device 102 (e.g., a blood pressure (“BP”) sensor) data may be processed by the driver software module appropriate for the medical or fitness device 102 resident on the service platform server 140 and the translated data may be stored on the service platform server 140. In this manner the processing of the electronic medical or fitness device data in the service platform server 140 using a driver appropriate for the electronic medical or fitness device 102 may enable storage of translated data that may be in a useful format to various data users. Paragraph [0075], the stored medical or fitness device 102 (e.g., a blood pressure (“BP”) sensor) data may be transmitted to a doctor's computer 138 or hospital server 142 as hypertext transfer protocol IP (HTTP/IP) packets, such as in response to queries posed to a website hosted by the service platform server 140. Paragraph [0018], the service platform server 140 may transmit a suitable request message to the wireless communication hub device 112 to obtain the access or data requested by the user, step 606.).
Regarding claim 15, Rajan further discloses wherein when said data of interest comprise new data generated by said medical device, said processing comprises extracting said new data from said at least one file and automatically updating said medical report based at least on said new data (Paragraph [0069], the service platform server 140 may “host” the latest data or status from electronic medical and fitness devices 102, 104, 108 for access by computer(s). Paragraph [0144], Paragraph [0143], At block 1906 the service platform server 140 may receive the electronic medical and fitness data from the communication device (e.g., the wireless M2M communications hub 112) via the wireless communications link. At block 1914 the service platform server 140 may update the stored electronic medical and fitness device data. At block 1916 the service platform server 140 may transmit the updated stored electronic medical and fitness device data to the other device (e.g., the physician's personal computer 138).).
Regarding claim 17, Rajan does not appear to explicitly disclose, but Newham teaches that it was old and well known in the art of medical device communication at the time of the filing wherein the medical device is a Cardiac Implantable Electronic Device (Newham, paragraph [0031], In some implementations, the implant device 200 may include but is not limited to cardiac pacemakers, implantable cardioverter-defibrillators (ICDs), implantable combination pacemaker-cardioverter defibrillator (PCDs).) to provide secure communications between implant devices and outside device (Newham, paragraph [0005]).
Therefore, it would have been obvious to one of ordinary skill in the art of medical device communication at the time of the filing to modify the medical device of Rajan as modified by Newham in claim 1, such that the medical device is a Cardiac Implantable Electronic Device, as taught by Newham, in order to provide secure communications between implant devices and outside devices.
Claims 4-5 are rejected under 35 U.S.C. 103 as being unpatentable over Rajan et al. (U.S. Pub. No. 2016/0029420) in view of Newham et al. (U.S. Pub. No. 2017/0259072), Contino et al. (U.S. Pub. No. 2012/0023293) and Lim Jung Kyo (KR 20150118205 EPO machine translation of the description), herein after “Kyo”.
Regarding claim 4, while Rajan further discloses applying known store-and-forward logic, it does not appear to explicitly disclose, but Kyo teaches that it was old and well known in the art of data transmission at the time of the filing wherein when transmitting said at least one file from said memory space to said remote platform fails, said at least one processor is configured to initiate again at least one attempt of transmitting said at least one file from said memory space to said remote platform (Kyo, paragraph [0056], when data transmission to the access point fails, the data transmitter 210 may perform the primary retransmission 420 at the same transmission rate (54 Mbps) according to the communication method of the embedded Wi-Fi communication chip.).
Therefore, it would have been obvious to one of ordinary skill in the art of remote data transmission at the time of the filing to modify the system of Rajan to incorporate the limitations above, as taught by Kyo, as this is the known store and forward technique for transmission devices which yields the predictable result of error handling.
Regarding claim 5, while Rajan further discloses applying known store-and-forward logic, it does not appear to explicitly disclose, but Kyo teaches that it was old and well known in the art of data transmission at the time of the filing wherein when a number of failed attempts of transmitting said at least one file from said memory space to said remote platform exceeds a threshold, said at least one processor is configured to delete said at least one file from said memory space (Kyo, paragraph [0065], when the order of retransmission is determined only up to the third order, the wireless communication terminal 200 automatically deletes the data requested for transmission or fails the data transmission failure if the data transmission fails even in the third retransmission step 540.)
Therefore, it would have been obvious to one of ordinary skill in the art of remote data transmission at the time of the filing to modify the system of Rajan to incorporate the limitations above, as taught by Kyo, as this is the known store and forward technique for transmission devices which yields the predictable result of error handling.
Claim 6 is rejected under 35 U.S.C. 103 as being unpatentable over Rajan et al. (U.S. Pub. No. 2016/0029420) in view of Newham et al. (U.S. Pub. No. 2017/0259072), Contino et al. (U.S. Pub. No. 2012/0023293) and Bernstein et al. (U.S. Pub. No. 2008/0319295).
Regarding claim 6, Rajan does not appear disclose, but Bernstein teaches that it was old and well known in the art of remote monitoring at the time of the filing wherein the at least one processor is further configured to delete said at least one file from said memory space after said at least one file has been correctly transmitted to said remote platform (Bernstein, paragraph [0119], the data collection module may be configured to delete the stored analyte data after transferring the analyte data to the remote location.) to ensure patient privacy, e.g., are HIPPA compliant (Bernstein, paragraph [0108]).
Therefore, it would have been obvious to one of ordinary skill in the art of remote monitoring at the time of the filing to modify the system above to include the limitations above, as taught by Bernstein, in order to ensure patient privacy, e.g., are HIPPA compliant.
Claim 16 is rejected under 35 U.S.C. 103 as being unpatentable over Rajan et al. (U.S. Pub. No. 2016/0029420) in view of Newham et al. (U.S. Pub. No. 2017/0259072), Contino et al. (U.S. Pub. No. 2012/0023293) and Nearhood et al. (U.S. Pub. No. 2015/0324549).
Regarding claim 15, Rajan further discloses viewingNearhood, paragraph [0093], receiving implantable cardiac device interrogation data 232, generating a preliminary device interrogation report 234; assigning to a reading physician 236, generating a final device interrogation report 238, saving in an electronic medical record 24. Paragraph [0143], The reading physician can then focus on reviewing the information, confirming it is correct, adding or modifying the information as desired, and quickly completing and electronically signing the report.) because a health care facility may face liability if a physician chooses not to review the interrogation report, or simply forgets, or if the physician does not understand the report and overlooks the clinically relevant information (Nearhood, paragraph [0006]).
Therefore, it would have been obvious to one of ordinary skill in the art of remote monitoring at the time of the filing to modify the method of Rajan to include validating, by a physician, the medical report via said remote platform, as taught by Nearhood, because a health care facility may face liability if a physician chooses not to review the interrogation report, or simply forgets, or if the physician does not understand the report and overlooks the clinically relevant information
Response to Arguments
Applicant's arguments filed July 20, 2026 regarding claims 1 and 4-17 being rejected under 35 U.S.C. §103 have been fully considered but they are not persuasive.
Applicant argues that a skilled person would have no reason to consult Rajan or Contino to solve problems associated with transferring clinical filed generated by a programming device used to interrogate or configure an implanted cardiac device.
In response to applicant's argument that Rajan and Contino are nonanalogous art, it has been held that a prior art reference must either be in the field of the inventor’s endeavor or, if not, then be reasonably pertinent to the particular problem with which the inventor was concerned, in order to be relied upon as a basis for rejection of the claimed invention. See In re Oetiker, 977 F.2d 1443, 24 USPQ2d 1443 (Fed. Cir. 1992). In this case, Rajan and Contino are determined to be in the field of the inventor’s endeavor. The field of endeavor of the claimed invention is considered to be transfer devices for transferring files from a device to a remote platform. The field of endeavor is ‘not limited to the specific point of novelty, the narrowest possible conception of the field, or the particular focus within a given field. See 2141.01(a). Both Rajan and Contino disclose similar structure and function as the claimed invention by providing a transfer device (i.e. wireless hub of Rajan and wireless device of Contino) which connects to a device via USB to receive a file and wirelessly transmit the file to a remote platform.
Applicant argues that Rajan and Contino are not combinable since the technical problems addressed by the two documents are unrelated.
In response to applicant’s argument that there is no teaching, suggestion, or motivation to combine the references, the examiner recognizes that obviousness may be established by combining or modifying the teachings of the prior art to produce the claimed invention where there is some teaching, suggestion, or motivation to do so found either in the references themselves or in the knowledge generally available to one of ordinary skill in the art. See In re Fine, 837 F.2d 1071, 5 USPQ2d 1596 (Fed. Cir. 1988), In re Jones, 958 F.2d 347, 21 USPQ2d 1941 (Fed. Cir. 1992), and KSR International Co. v. Teleflex, Inc., 550 U.S. 398, 82 USPQ2d 1385 (2007). In this case, The combination is a simple substitution of the known use software interface models that mirror the types of devices that can be connected to computers via USB of Rajan for the use of emulating the behavior of a Universal Serial Bus (USB) storage device Contino to obtain the predictable result to one of ordinary skill in the art of allowing a wireless device to be treated as locally attached mass storage by non-driver parts of the operating system and applications.
Applicant argues that none of the prior art documents teach that the file is generated by the programming device.
In response, Newham teaches that the processor of the remote device 300 (interrogator/programming device) includes a control system 330 capable of performing some or all of the methods described herein (Paragraph [0043]). Paragraph [0092] of Newham describes a method of calculating, estimating, processing, and/or analyzing physiological data of the implant device and storing the raw or analyzed physiological data in memory. Therefore, Newham contemplates/teaches the remote device 300 (interrogator/programming device) calculating, estimating, processing, and/or analyzing physiological data of the implant device and storing the raw of analyzed physiological data in memory, construed as generating a file from the data received from the implant device.
The remainder of the arguments have either: been addressed above; fail to comply with 37 CFR 1.111(b) because they amount to a general allegation that the claims define a patentable invention without specifically pointing out how the language of the claims patentably distinguishes them from the references; amount to arguments that the references fail to show certain features of the invention (i.e. use of e the transfer device without modification of the programming device, ensuring the only interfaces officially supported by the programming device are used), which are not recited in the rejected claim(s) (Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993).); and/or are arguments against the references individually (one cannot show nonobviousness by attacking references individually where the rejections are based on combinations of references. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re Merck & Co., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 1986)).
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Devin C. Hein whose telephone number is (303)297-4305. The examiner can normally be reached 9:00 AM - 5:00 PM M-F MDT.
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, Jason B. Dunham can be reached at (571) 272-8109. 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.
/DEVIN C HEIN/Examiner, Art Unit 3686
Prosecution Insights