Invalidity Search Report – ICT | Synoptic IP
Go to Main Website
Synoptic IP · Simplified Solutions

Invalidity Search Report – ICT

Device for short-range communication, adapted to provide access to a remote service

US9924448B2
Report Date: April 20, 2026

1 · Project Methodology

1.1 Methodology

StepTask
I – Understanding of the Subject Matter
  • Analyze the patent(s) to identify technological aspects, potential weaknesses in claim support, enablement, and specification gaps.
  • Examine file wrappers of the patents-in-suit and their international family members to uncover key insights.
II – Keyword-Based Patent Search and Analysis
  • Formulate a robust search strategy using keywords, patent classifications (e.g., CPC/IPC), applicant and inventor names, priority dates, citations and their combinations in major patent databases (e.g., Questel Orbit and/or PatSeer) and AI-based tools.
  • Conduct a thorough analysis of retrieved patent and non-patent literature to identify the most relevant prior art references.
  • Analysis of the identified patents/patent-applications to shortlist potentially relevant patents/patent-applications.
III – Detailed Analysis
  • Detailed analysis of the shortlisted patents/patent applications.
  • Analyze identified patents using two approaches:
    • Claimed Methods: Use the invention’s claimed methods as the Initial Source of Information (ISI) to identify similar technical solutions.
    • Problem-Solution: Use the problem addressed by the invention as the ISI to identify alternative solutions or methods in the same technical domain.
IV – Non-Patent Literature Search
  • Conduct searches for non-patent literature (e.g., academic papers, technical journals, conference proceedings) using databases like Google Scholar, IEEE Xplore, or PubMed.
  • Identify disclosures that may impact the novelty or non-obviousness of the invention.
  • Analyze and categorize relevant non-patent literature based on its technical relevance.
VI – Preliminary Report Preparation
  • Preparation of a preliminary report containing prior art publication numbers, key excerpts from the references, and a summary for your review and feedback.
V – Final Report Preparation
  • Collate all relevant patents, patent applications, and non-patent literature identified during the search.
  • Present findings in a structured MS Word document, including:
    • Bibliographic data (e.g., patent numbers, publication dates, assignees, inventors).
    • Summaries of relevant prior art, mapping with the patent excerpts.
  • Analysis of novelty and non-obviousness based on the identified prior art.

1.2 Data Sources

Data sources applicable to this search
Data sources NOT applicable to this search
Data SourcesIndustrial Design SearchSpecial Databases
  • Thomson Innovation
  • Questel Orbit
  • Patent Insight Pro
  • National Patent Databases of Individual (100+) Countries
  • Questel Orbit Design Patent Module
  • Design View
  • National Industrial Design Databases of Individual Countries
  • SciFinder
  • Patent Lens
  • EMBL-EBI (EPO, JPO, KIPO and USPTO)
  • NCBI (USPTO, EPO and JPO)

Non-Patent Literature Databases

Journal Articles: Thomson Innovation, Dialog, ScienceDirect, Scitation, Springerlink, IEEE, ACM, PubMed, PubChem, MedLine, PaperChem, Google Scholar, JournalSeek, Chemical Engineering and Biotechnology Abstracts, Food Science and Technology Abstracts, Biosys, Embase, Compendex, INSPEC, Others by the Technical Domain

Books: Google Books, Other Online Books Archives

Academic Projects/Thesis: Dissertation Abstracts Online, Stanford University Library, Harvard University Library, 99 Resources, Open Thesis, DeepDyve

Conference Proceedings: Inside Conferences, Specific Conference Archives/Websites by the Technical Domain

Product Literature & Standards: Company Websites, Youtube Videos, Product Brochures, Regulatory Submission Databases like FDA, CRDH, etc. Specific sources based on technical domain like National Technical Information Service, Transportation Research Information Services, International Construction Database

Foreign Language Databases: Non-patent literature sources of individual countries (example): China National Knowledge Infrastructure (CNKI), WanFang Data, J-Stage, CiNii); Traditional Knowledge Digital Library (TKDL) of India

1.3 Patent Coverage

Worldwide Patent search in 104+ Jurisdictions using Questel Orbit and PatSeer database.

42 Full Text Authorities:

EPWOUSJPCNKRCADEFRGBESAUINCHATBRTHRUPHSENODKFIBENLLUMXAPCODDEAILMAMCOATWTJKGAMUZMDGE

Full Text Machine Translations in English:

JPKRCNFRDEDKFIRUBENLLU

104+ Bibliographic Authorities

2 · Project Overview

2.1 Objective & Background

The client requested that Synoptic IP conduct a prior art search to identify patent references that could challenge the validity of all claims in Patent No. US9924448B2, titled ‘Device for short-range communication, adapted to provide access to a remote service’.

2.2 Search String

The following search strings were used to identify relevant patents and published applications.

Questel Orbit Patent Database

1Title, Abstract, Claims and Description
((SHORT RANGE OR “NFC” OR (NEAR 2D FIELD) OR BLUETOOTH) AND ((REMOTE OR ONLINE OR INTERNET OR CLOUD) 3D (SERVICE? OR STREAMING OR MEDIA OR MULTIMEDIA OR MULTI MEDIA OR STORAGE OR APPLICATION)) AND (((STOR+ OR SAV+) 5D (TEMPORAR+ OR VOLATILE)) AND (HUB 7D (PORT? OR JACK OR “USB”))) AND ((DELET OR ERAS+ OR REMOV+) 5D (IDENTIF+)))/TI/AB/CLMS/ICLM/DESC/ODES
Date restriction: PRD <= 2015-06-26
2Title, Abstract, Claims and Description
((HUB AND (REMOTE OR ONLINE OR INTERNET OR CLOUD) 3D (SERVICE? OR STREAMING OR MEDIA OR MULTIMEDIA OR MULTI MEDIA OR STORAGE OR APPLICATION)))/TI/AB/CLMS/ICLM AND ((SHORT RANGE OR “NFC” OR (NEAR 2D FIELD) OR BLUETOOTH) AND ((DELET OR ERAS+ OR REMOV+) 5D (IDENTIF+))/TI/AB/CLMS/DESC/ODES/ADB/ICLM
Date restriction: PRD <= 2015-06-26
3Title, Abstract and Claims
((REMOTE OR ONLINE OR INTERNET OR CLOUD) 3D (SERVICE? OR STREAMING OR MEDIA OR MULTIMEDIA OR MULTI_MEDIA OR STORAGE OR APPLICATION)) AND (SHORT_ RANGE OR “NFC” OR (NEAR 2D FIELD) OR BLUETOOTH) AND (DELET OR ERAS+ OR REMOV+) 5D (IDENTIF+))/TI/AB/CLMS/ICLM
Date restriction: PRD <= 2015-06-26
4Title, Abstract and Claims
(REMOTE OR ONLINE OR INTERNET OR CLOUD) 3D (SERVICE? OR STREAMING OR MEDIA OR ULTIMEDIA OR MULTI MEDIA OR STORAGE OR APPLICATION)) AND (SHORT RANGE OR “NFC” OR (NEAR 2D FIELD) OR BLUETOOTH) AND (((STOR+ OR SAV+) 5D (TEMPORAR+ OR VOLATILE)) AND (HUB 7D (PORT? OR JACK OR “USB”))))/TI/AB/CLMS/ICLM
Date restriction: PRD <= 2015-06-26
5Citation-Based Search
CITATION = (US10230783 OR US6910064 OR US10263918 OR US11223882 OR US10104145 OR US10798244 OR US10135823 OR KR100777811B1 OR US10972523 OR US10200523 OR US10846683)
Date restriction: PRD <= 2015-06-26

Non-Patent Literature Search

6Non-Patent Literature
HUB (REMOTE SERVICE) (SERVICE IDENTIFICATION) (TEMPORARY MEMORY)
7Non-Patent Literature
HUB PORTS CLOUD IDENTIFICATION ((DELETE OR ERASE) IDENTIFICATION)
8Non-Patent Literature
HUB REMOTE STREAMING ((DELETE OR ERASE) IDENTIFICATION) MEMORY

2.3 Date Restriction

Search was conducted to identify any patent filed/published till 23 August 2002.

3 · Patent Results – Relevant Results Table

The table summarizes the mapping of relevant results identified in the prior art search analysis.

Key-features (US9924448B2) US2012182939A1 JPH07317429 (A) US6910064B1
Key-feature 1A hub device, comprising: Para [0057] Para [0046] Column: [1-2] & Line: [65-08]
Column: [2] & Line: [09-25]
Key-feature 2An interface configured for communicating with a terminal using a short-range wireless connection; Para [0057]
Para [0084]		 Para [0044]
Para [0046]		 Column: [2] & Line: [09-25]
Key-feature 3A circuit configured for: connecting to a remote service Para [0063]
Para [0085]		 Para [0046] Column: [2] & Line: [09-25]
Key-feature 4Receiving from the terminal a request to access the remote service, the access request comprising identification parameters for said service, Para [0098]
Para [0101]
Para [0098]		 Para [0046]
Para [0116]		 Column: [7] & Line: [24-31]
Column: [07-08] & Line: [63-04]
Key-feature 5Storing in memory the identification parameters of the request received, in order to send to the remote service a second access request including the identification parameters, Para [0091]
Para [0098]
Para [0101]		 NA NA
Key-feature 6Upon response from the remote service to the second request, transferring data relating to the service, Para [0105]
Para [0118]		 Para [0046] Column: [8] & Line: [17-27]
Column: [1-2] & Line: [65-08]
Key-feature 7identification parameters of the request received from the terminal are stored temporarily in the memory, Para [0091]
Para [0098]		 NA NA
Key-feature 8Hub device comprises a plurality of connection ports, configured for: (a) identifying a port based on the request, and (b) upon response from the remote service to the second request, associating the identified port with the remote service. Para [0061]
Para [0082]
Para [0118]
Para [0137]		 Para [0034]
Para [0037]
Para [0044]		 Column: [2] & Line: [09-25]

4 · Search Summary – Prior Art Analysis

US2012182939A1
Telehealth wireless communication hub and service platform system
TitlePublication DateFiling DateInventorAssignee
Telehealth wireless communication hub and service platform system July 19, 2012 January 13, 2012 Rajeev D. Rajan | Mark D. Jerger | Robert B. Ganton | Kumar V. Senthil | Jatin C. Kadakia | Vishwajeet Lohakarey | Thien H. Lee | Christopher D.B. Talbot Capsule Technologies Inc
Abstract Methods and devices provide a wireless communications hub device and services enabling remote access to electronic medical or fitness devices in a manner that simplifies device networking. 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. The system enables discovery of the wireless communication hub device and connected electronic medical or fitness devices.
Key-feature 1 — A hub device, comprising:
Para
[0057]
FIG. 1A illustrates system components that may be included in the communication system. A variety of electronic medical or fitness devices (e.g., a blood pressure sensor, a glucose sensor, and a scale) may transmit data via a local network 105 (such as a local area wireless network (e.g., WiFi, Bluetooth, Zigbee, and ANT+) or wired network (e.g., USB)) to the wireless communication hub device 112, which packages the data encrypted and transmits it via a wireless communication link, such as a wireless wide area network 130 (e.g., 3G cellular wireless network), to a service platform server 140 where the data may be unpacked and stored in a database or transferred to other systems where the data may be stored and processed.
Comment: Para [0057] + FIG. 1A give a complete system diagram of the hub receiving data from multiple devices and forwarding it encrypted to the remote server.
Key-feature 2 — An interface configured for communicating with a terminal using a short-range wireless connection;
Para
[0057]
FIG. 1A also provides a high-level illustration of the flow of data from various electronic medical and fitness devices through the hub over three short range radio protocols. The wireless communication hub device acts as a gateway that securely enables wireless transport of data or information from the various electronic medical and fitness devices through the service platform server to the caregiver or provider’s servers and databases located in the Internet cloud.
Para
[0084]
Since the wireless communication hub device is intended to be simple for users to implement, it may include a very rudimentary user interface. For example, the processor 301 may be coupled to one or more light emitting diodes (LEDs) 334 for communicating status, and to one or more buttons 332 for receiving simple user command inputs.
Comment: The cited text describes short-range links to medical/fitness devices, not to a user “terminal” (computer). The user terminal interacts with the server via web browser/Internet; direct short-range hub-to-terminal communication is not clearly shown.
Key-feature 3 — A circuit configured for: connecting to a remote service
Para
[0063]
The service platform server 140 may be configured to provide a variety of data and communication services related to wireless communication hub devices 112, the electronic medical and fitness devices 102, 104, 108 that may be connected to them, and data that may be obtained from such electronic medical and fitness devices. Such services are generally referred to herein as “service platform services.”
Para
[0085]
While FIG. 3A shows the various components of the wireless communication hub device 112 as separate integrated circuits, several components may be integrated into a single VLSI chip. For example, many modern cellular telephone transceivers include a powerful processor, transceivers for connecting to WiFi networks and Bluetooth enabled devices, a built-in GPS receiver, and circuitry for connecting to wired connections such as a data port for receiving USB, FireWire and/or Ethernet connections.
Comment: Multiple citations (cellular transceiver, service platform server functions, registration flow).
Key-feature 4 — Receiving from the terminal a request to access the remote service, the access request comprising identification parameters for said service,
Para
[0098]
At block 514, the processor 301 may communicate the identifier of the hub device 112 to the service platform server 140 to identify itself and register with the service platform server 140. During this time, the user may access the service platform server 140 from any computer with a web browser and access to the Internet. In an embodiment, the number used to identify a hub device 112 to the service platform server 140 may be a six-digit number. At block 520, the service platform server 140 validates the number entered by the user with the number provided by the hub device 112 during its own online registration.
Para
[0101]
Once the configuration and registration process is completed, the wireless communication hub device 112 can be moved to any location that has cellular wireless network connectivity. As electronic medical or fitness devices coupled to the wireless communication hub device 112 are identified, the wireless communication hub device 112 may identify the electronic medical or fitness devices to the service platform server 140, such as by transmitting their media access control (MAC) identifier (ID).
Comment: The registration flow (paras [0098], [0101]) is user then server (browser enters 6-digit code) and separately hub then server (sends its own ID). The hub does not directly receive an access request from the terminal.
Key-feature 5 — Storing in memory the identification parameters of the request received, in order to send to the remote service a second access request including the identification parameters,
Para
[0091]
FIG. 3E is a data structure diagram illustrating potential configurability functions and parameters that may be stored in a memory 302 resident in a wireless communication hub device 112. The memory 302 may contain: transaction data upload flags 352, Quality of Service (QoS) parameters, data call periodicity parameters 356, URL and DNS port information 358, a transaction storage limit parameter 360, a storage limit 362, security/encryption mechanisms 363, a time out parameter 364, a configuration file 366, and a hub ID 368, such as the wireless communication hub device’s identification code (e.g., a six-digit number printed on the housing).
Comment: Memory (para [0091]) stores persistent hub config, hub ID, drivers, QoS, etc. There is no disclosure of the hub receiving a terminal request, temporarily buffering its identification parameters, and then generating/sending a “second access request” on behalf of the terminal. The hub’s own ID registration is one-time and not portrayed as a relayed/stored terminal request.
Key-feature 6 — Upon response from the remote service to the second request, transferring data relating to the service,
Para
[0105]
If an electronic medical or fitness device provides data for communication to the service platform server 140 or a user computer 138, such data is received by the hub device 112 and relayed to the service platform server 140. The wireless communication hub device 112 may encapsulate the device data within IP packets so that the data can be tunneled through the Internet 114 for processing by the service platform server 140 using an appropriate driver software.
Para
[0118]
In response to receiving a device or data access request from a user, 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. Upon receiving this request, the wireless communication hub device 112 may query the indicated electronic medical or fitness device for the requested data. The wireless communication hub device 112 receives the native format electronic medical or fitness device data and packages the data into IP packets that can be tunneled via the Internet 114 to the service platform server 140.
Comment: Paras [0105], [0118] describe the exact sequence: ‘server sends request’ → ‘hub queries device’ → ‘hub packages native data’ → ‘tunnels to server’.
Key-feature 7 — identification parameters of the request received from the terminal are stored temporarily in the memory,
Para
[0091]
The memory 302 may contain: transaction data upload flags 352, Quality of Service (QoS) parameters, data call periodicity parameters 356, URL and DNS port information 358, security/encryption mechanisms 363 (e.g., AES encryption), a time out parameter 364, a configuration file 366, and a hub ID 368. In the various embodiments, the memory 302 may contain additional parameters, functions, algorithms, software, and/or controls as necessary to perform the methods and functions discussed herein.
Comment: Memory (para [0091]) stores persistent hub config, hub ID, drivers, QoS, etc. There is no disclosure of the hub receiving a terminal request, temporarily buffering its identification parameters, and then generating/sending a “second access request” on behalf of the terminal.
Key-feature 8 — Hub device comprises a plurality of connection ports; (a) identifying a port based on the request; (b) upon response, associating the identified port with the remote service.
Para
[0082]
The processor 301 may also be coupled to one or more wired network connection sockets, such as a USB port 310, a FireWire port 311 and/or an Ethernet socket 312. In other embodiments, 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.
Para
[0137]
Upon receiving the data message, the wireless communication hub device 112 may recognize the particular electronic medical and fitness device providing the data. This may be accomplished based upon the particular communication port through which the data signal was received or information provided with the data message, such as a device identifier. As part of this step, the wireless communication hub device processor 301 may obtain the IPv6 address, MAC ID or other unique identifier for the reporting electronic medical and fitness device that is known to be service platform server 140.
Comment: Para [0082] lists multiple USB/FireWire/Ethernet ports; para [0137] explicitly states the hub identifies the device “based upon the particular communication port through which the data signal was received” and associates it with the service platform.
JPH07317429 (A)
System and method for caching data
TitlePublication DateFiling DateInventorAssignee
System and method for caching data September 11, 2014 May 22, 2014 Hug; Joshua D. NA
Abstract A method of obtaining radio content from a remote electronic device for a user electronic device includes transmitting a request for radio media content to a first remote electronic device via a network. Radio media content that includes a plurality of media data files is received via the network. The received plurality of media data files are stored in a storage device of the user electronic device. A radio playlist that defines a rendering sequence for the plurality of media data files is requested.
Key-features 1, 2, 3, 4, 6 — All mapped to Para [0046]
Para
[0046]
Proxy computer 54 may function as an Internet gateway for personal media device 12. Accordingly, personal media device 12 may use proxy computer 54 to access media distribution system 18 via network 30 (and network 32) and obtain media content 16. Specifically, upon receiving a request for media distribution system 18 from personal media device 12, proxy computer 54 (acting as an Internet client on behalf of personal media device 12), may request the appropriate web page/service from computer 28 (i.e., the computer that executes media distribution system 18). When the requested web page/service is returned to proxy computer 54, proxy computer 54 relates the returned web page/service to the original request (placed by personal media device 12) and forwards the web page/service to personal media device 12. Accordingly, proxy computer 54 may function as a conduit for coupling personal media device 12 to computer 28 and, therefore, media distribution system 18.
Para
[0044]
Personal media device 12 may be connected to proxy computer 54 via a docking cradle 60. Typically, personal media device 12 includes a bus interface that couples personal media device 12 to docking cradle 60. Docking cradle 60 may be coupled (with cable 62) to e.g., a universal serial bus (USB) port, a serial port, or an IEEE 1394 (FireWire) port included within proxy computer 54.
Para
[0116]
Media distribution system 18 is typically a subscription-based service. When accessing media distribution system 18, user 14 must provide user “credentials” that identify the user (e.g., user 14) and/or the device (e.g., device 12) to media distribution system 18. Upon receiving these credentials, media distribution system 18 may attempt to verify the credentials and, if verified, grant user 14 and/or device 12 access to media distribution system 18. The credentials may include, but are not limited to, a user name, a user password, a user key, a device name, a device password, a device key, and/or one or more digital certificates.
Key-features 5 & 7 — Not found in this reference
NA — No disclosure of temporary storage of identification parameters or second access request mechanism found.
Key-feature 8 — Plurality of connection ports
Para
[0034]
Media distribution system 18 is typically a server application that resides on and is executed by computer 28 (e.g., a server computer) that is connected to network 30 (e.g., the Internet). Computer 28 may be a web server (or series of many connected servers) running a network operating system.
Para
[0044]
Personal media device 12 may be connected to proxy computer 54 via a docking cradle 60. Docking cradle 60 may be coupled (with cable 62) to e.g., a universal serial bus (USB) port, a serial port, or an IEEE 1394 (FireWire) port included within proxy computer 54.
Comment: This reference discloses a plurality of connection ports on the proxy computer; however, it does not describe identifying a specific port based on the request or associating any port with the remote service upon receiving a response.
US6910064B1
System of delivering content on-line
TitlePublication DateFiling DateInventorAssignee
System of delivering content on-line June 21, 2005 September 21, 2000 Shaun Astarabadi; Glenn Swonk; Andrew McCloskey Toshiba America Information Systems Inc.
Abstract A system and method of providing digitized media content from a remote server through a data network is disclosed. A local content server at the premises of the subscriber hosts an agent process and includes a memory for storing the digitized content. The digitized content may be streamed on demand to client devices through the agent process for a subscription period. However, the subscriber is prevented from otherwise accessing the digitized content from the local server. The digitized content delivered from the remote server to the local server is combined with encoded data identifying the subscriber.
Key-features 1, 2, 3 — Column [1-2] & [2] Lines [65-08] / [09-25]
Col [1-2]
Ln [65-08]
Embodiments of the present invention are directed to providing media content to subscribers in an on-line environment. A remote server may provide digitized media content to a subscriber’s local server through a digital communication network for storage at a local memory. The local server is configured to stream the media content data to users at client devices.
Col [2]
Ln [09-25]
FIG. 1 shows a network topology including a local server 2 coupled to client computer workstations 20 through links 8 and an integrated hub 4. In the illustrated embodiment, the integrated hub provides a plurality of Ethernet connections 6, each Ethernet connection 6 being adapted to be coupled to a distinct computer workstation 20 through a corresponding data link 8. The local server 2 also includes a parallel port 10 coupled to a parallel port printer 12 and an Ethernet port 16. The Ethernet port 16 may be coupled to a broadband data source 26 such as a cable service or digital subscriber line (DSL) service through a compatible broadband modem 14. Alternatively, the port 16 may be coupled to other broadband data sources such as broadband satellite or terrestrial wireless communication services.
Comment on KF2: US’064 describes wired Ethernet connections/links; however, it does not describe wireless connections.
Comment on KF3: US’064 discloses that an integrated hub is part of a local-server topology that enables connection to a remote server.
Key-feature 4 — Receiving identification parameters for said service
Col [7]
Ln [24-31]
A user at a client computer workstation 20 may request that the remote server 18 provide contents such as video and/or audio content to be stored at the HDD 56 in digital form, and then streamed to any client computer workstation 20 on demand for presentation on demand.
Col [8]
Ln [05-16]
FIG. 5 illustrates a process by which the remote server 18 provides digitized content to the agent process at the local server 2 in response to a user request. At step 302, the remote server 18 receives a request for a particular content title from the agent process. In addition to identifying the particular requested title, the request also includes information from which the identity of the subscriber may be obtained. For example, the request may include information identifying the particular local server 2 which is cross-referenced with the subscriber’s identity. The request may also specifically identify the subscriber by a subscriber’s name or by an account number.
Key-features 5 & 7 — Not found in this reference
NA — No disclosure of temporary storage of identification parameters or second access request mechanism found.
Key-feature 6 — Upon response from the remote service, transferring data relating to the service,
Col [8]
Ln [17-27]
At step 304 the remote server 18 retrieves encoded digital data identifying the subscriber. At step 306 the remote server 18 retrieves the digitized content title from a content server as identified in the received request. Step 308 combines the encoded identification data retrieved at step 304 with the digitized content title retrieved at step 306 to provide modified digitized content. The combined data is then compressed and transmitted back to the agent process at step 310 to be stored on the HDD 56. The digitized content stored on the HDD 56, therefore, includes the encoded data identifying the subscriber.
Key-feature 8 — Plurality of connection ports
Col [2]
Ln [09-25]
FIG. 1 shows a network topology including a local server 2 coupled to client computer workstations 20 through links 8 and an integrated hub 4. In the illustrated embodiment, the integrated hub provides a plurality of Ethernet connections 6, each Ethernet connection 6 being adapted to be coupled to a distinct computer workstation 20 through a corresponding data link 8.
Comment: US’064 discloses that the integrated hub provides a plurality of Ethernet connections; however, it does not describe identifying a specific port based on the request or associating any port with the remote service upon receiving a response.

4.2 · Non-Patent Literature Results

The Promise of Wireless: An Overview of a Device-To-Cloud mHealth Solution
Publication Date2012
AuthorRajeev Rajan
PublisherIEEE / Academic Journal
DOI / Linkhttps://doi.org/10.2345/0899-8205-46.s2.26

This article aims to give an overview of the process of creating and using some mHealth solutions. Several challenges were dealt with in order to launch Qualcomm’s 2net™ wireless hub and mHealth cloud service platform.

  • Enabling medical devices to work with multiple radio technologies and software
  • Determining the optimum cellular carrier and cellular technology
  • Managing lengthy product life cycles in healthcare vs. short product life cycles in wireless, while designing for regulatory compliance and process
  • Harnessing the cloud
  • Realizing the user experience

Figure 1 illustrates a typical use-case scenario for RHM: A patient consumer uses a wireless-assisted medical device to take a reading. The data is then sent to an mHealth gateway device, which then in turn wirelessly sends it over the cellular network to the healthcare provider.

The key efficiency enhancer in the device-to-cloud mHealth solution is the hub device, which can be used in a home or office setting. Figure 2 shows archetypal features of a universal hub, illustrating the broad cross-section of spheres involved.

A key common feature of the hub is its ability to communicate with multiple devices, such as glucose meters, blood-pressure monitors, and pulse-oximeters, in some concurrent fashion. To add to this complexity, these devices may use the same short-range radio (e.g., Bluetooth), or different short-range radios (e.g., Bluetooth, ANT+, Zigbee).

Security is important, and the hub should not communicate with any other device until it is authorized to do so by the platform so as to ensure data is protected. Initial meetings during the development process with several medical device companies evidenced a wide gap in competencies between the cellphone centric experts and medical device experts for hub-to-medical-device interaction.

The cloud platform is designed to interoperate with different medical devices, mHealth gateways, and applications, effecting end-to-end wireless connectivity while allowing providers and their systems access to the data.

Full PDF Report

Invalidity Search Report – ICT · US9924448B2

Invalidity Search Report – ICT (US9924448B2)

April 20, 2026 · Synoptic IP

Download PDF

5 · Disclaimer

⚠ Important Notice

The prior art search for the subject invention has been conducted based only on the keywords listed in the document which in turn have been derived from the key features of the invention mentioned in the document. Furthermore, the information contained herein has been obtained from data sources believed to be reliable. Synoptic IP disclaims all warranties as to the accuracy, completeness or adequacy of such information. No opinion, unless clearly stated, is expressed or implied. Finally, the search results identified are only up to the date of this report.


Neither Synoptic IP nor any subsidiary of Synoptic IP (Together, “Synoptic IP”), nor any of their directors, officers, employees, agents or representatives (Together, “PERSONNEL”), provides legal services or legal advice in any part of the world. Since Synoptic IP is not a law firm, it does not and cannot render legal services or legal advice to the general public and is not engaged in the practice of law.

Synoptic IP
Simplified Solutions
Visit synopticip.com ↗