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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on February 13, 2026 has been entered.
Status of the Claims
The office action is in response to the claim amendments and remarks filed on January 21, 2026 for the application filed April 17, 2024. Claim 1 has been amended and claims 2-3 have been cancelled. Claims 1 and 4-16 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 and 7-15 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 programming device (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 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 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.) 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 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.
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 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, 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.), 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.),
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).).
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 a 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 a 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 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 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 January 21, 2026 regarding claims 1 and 4-16 being rejected under 35 U.S.C. §103 have been fully considered but they are not persuasive.
Applicant argues that Rajan does not disclose the detection that a file has been written into said memory space as recited in claim 1.
In response, Rajan discloses in paragraph [0094] that the communication hub includes 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. Store and forward logic is construed as detecting that a data/file has been written into said memory space of the wireless communication hub/transfer device before relaying that data/file at a later time to a destination.
Applicant’s arguments pertaining to the newly added shared memory space limitation or moot in view of the new grounds of rejection.
Conclusion
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