DEVICES, SYSTEMS, AND METHODS TO ACTIVELY OR PASSIVELY SCAN RFID MICROCHIPS IN COMPANION ANIMALS AND OPTIMIZE THE WORKFLOW TO REUNITE ANIMALS WITH OWNERS

Abstract

Devices, methods, and systems to actively or passively scan an RFID microchip in a companion animal, transmit the associated data to software, allow users to augment the data with additional information to create a post, and allow users to interact in the software in the context of reuniting the lost animal with its owner.

Claims

1. A system for locating and reuniting a lost companion animal with its owner, the system comprising: a. a portable scanning device including an antenna configured to read an ISO 11784/11785 microchip implanted in the animal (operable at approximately 125 kHz, 128 kHz, or 134 kHz), the scanning device further comprising a memory configured to store a unique identifier read from the microchip along with location data of the scanning device independent of any external device; b. a freestanding unit configured to detachably hold the scanning device, the freestanding unit enabling the scanning device to operate in an autonomous passive scanning mode to read microchips of animals that come into proximity without human intervention; c. a software application in communication with the scanning device, the software application being configured to receive the unique identifier (and the location data) from the scanning device and to initiate a lookup of the unique identifier in at least one pet microchip registry, and further configured to provide a user interface that allows users to create and share electronic posts containing information about the scanned animal; d. wherein the software application enables communication between a user who scanned the animal and a user associated with the microchip ID via the user interface without disclosing personal contact information of either party unless permission is granted; and e. a database in communication with the software application, the database being configured to securely store the unique identifier, the location data, and the information in the posts, and to allow the stored data to be searched by one or more geographic location parameters including region, city, or a radius distance from a specified location.

2. The system of claim 1, wherein the scanning device is configured to be powered by and attached to a mobile computing device such that the mobile computing device provides operating power to the scanning device and enables handheld use of the scanning device, thereby allowing an individual to scan the companion animal's microchip in the field and automatically transmit the unique identifier and location data to the software application.

3. The system of claim 2, wherein the scanning device communicates with the mobile computing device via a wireless connection selected from the group consisting of Bluetooth and Wi-Fi, to transmit the microchip unique identifier and location data to the software application in real time.

4. The system of claim 1, wherein the database is configured to be searchable by geographic location, including search filters for a particular region, city, or a specified distance radius from a given location (thereby allowing users to find posts or scan records near a location of interest).

Description

BRIEF DESCRIPTION OF DRAWINGS

[0009] For a more complete understanding of the invention, reference is made to the following description and accompanying drawings, in which:

[0010] FIG. 1 is a system diagram illustrating a platform for geolocating and finding companion animals, according to an embodiment of the invention;

[0011] FIG. 2 is a user interface of an application for viewing and sharing information about scanned companion animals;

[0012] FIG. 3 is a user interface screen for connecting to a scanning device to read an animal's microchip;

[0013] FIG. 4 is a screen displaying scan results after the application reads the animal's microchip;

[0014] FIG. 5 is a map interface for searching microchip scan events and be-on-the-lookout (BOLO) locations; and

[0015] FIG. 6 is an application interface for connecting to a freestanding scanning unit (e.g., a Totem device) over Bluetooth.

DETAILED DESCRIPTION OF THE INVENTION

[0016] The present invention will now be described in detail with reference to the accompanying drawings, which illustrate exemplary embodiments of the system. It is to be understood that the embodiments and specific terminology are for illustrative purposes only, and should not be construed as limiting the scope of the invention as defined by the claims.

[0017] Referring to FIG. 1, the system is designed to facilitate the identification of a lost companion animal and the reunification with its owner through integrated hardware and software components. A companion animal 100 (for example, a dog or cat) is implanted with a standard RFID microchip 101 that stores a unique identification code (referred to as microchip unique identifier 102). To read this microchip, the system includes a portable scanning device 103 equipped with an RFID antenna 106 and reader circuitry. The scanning device 103 contains a microcontroller 104 that has a microprocess 105 to process RFID signals and manage data communication.

[0018] In one mode of operation (active, handheld use), the scanning device 103 is connected to a user's mobile computing device, such as a smartphone. This connection can be physicalfor instance, via a magnetic connector 305 that attaches the scanner to the smartphone. Through this connector, the scanner can draw power from the phone (shown as power line 302 in the schematic) and establish data communication between the scanner's electronics 304 and the phone's software. In alternative implementations, the scanner 103 may connect to the phone wirelessly (e.g., via Bluetooth or Wi-Fi), enabling the phone to control the scanner and receive scan data without a direct cable.

[0019] In another mode of operation (passive, autonomous use), the scanning device 103 can be placed in a freestanding housing or stationary unit (e.g., a Totem device) to function continuously without being handheld. In this passive mode, the freestanding unit holds the scanner and may be installed in a fixed location such as a neighborhood entrance, a park, or near a home. The scanner 103 periodically emits reading fields and automatically scans any animal that comes within range, without human intervention. To support prolonged autonomous operation, the freestanding unit provides power 107 to the scanner. In one embodiment, the unit can use battery power (for example, a 5V rechargeable lithium-polymer battery for the microcontroller and a 9V battery for the RFID reader and antenna). In another embodiment, the unit is powered via a wired connection-such as a 5V DC supply from a USB power adapter plugged into a wall outlet, or a solar-powered setup feeding a regulator-ensuring the scanner remains continuously active. Once the power supply is attached and activated, the user can place the scanning device 103 and its mounting unit at the desired location, where it will operate independently in scanning animals that pass by.

[0020] Data collected by the scanning device 103 (in either mode) is relayed to a software application for processing. In the active/handheld scenario, the user's mobile application 111 (running on their smartphone) communicates with the scanner 103, receives the microchip ID 102 that was read, and typically also obtains the scan's timestamp and geolocation (using the phone's GPS). In the passive scenario, the freestanding unit could have its own communication module or also use a nearby device to send data; in both cases, the information eventually reaches the central system. The software application 111 is connected to a network 112 (such as the Internet) and communicates with a backend server 118. The backend server hosts a cloud-based service with a database 114 (also referred to as a central repository) that stores information 113 about pets, microchip IDs, user-generated posts, and user accounts. The server exposes an API 116 to the mobile application, allowing the app to send new scan data and retrieve matching information. The system also utilizes cloud services 117 associated with the serverfor example, to store photos of found animals efficiently and to send notification emails or messages according to business logic (such as alerts for matching lost/found pets).

[0021] FIG. 1 also illustrates various user roles in the system. For instance, a user who finds a stray animal and scans its microchip using scanner 103 can be considered a scanning user 108 (the creator of a scan event/post 115). Another user may be a pet owner who has lost their animalthis pet owner user 110 would create a lost-pet report/post 115 in the system (a lost post). There can also be users who find an animal but are unable to scan it (they can create a manual found post 115), and users who simply browse or monitor the network to help reunite animals with owners (such a volunteer helper is denoted as 109 in the figure). All of these users interact with the system through the software application 111 on their devices, which presents a unified interface for creating and viewing posts and receiving notifications.

[0022] Referring to FIG. 2, the system's mobile application 111 is shown displaying its default home screen (identified by reference 217), which provides a feed of lost-and-found pet posts. In this feed, two main types of posts are presented: scan posts (reference 200) and lost posts (reference 201). A scan post is created when a pet's microchip is scanned by the device, whereas a lost post is created by a pet owner or user to report a missing animal. The feed displays these posts in a list format, potentially intermixed (e.g., a scan post followed by a lost post), along with contextual information such as the animal type and community input.

[0023] Each post in the feed includes a photograph of the animal and descriptive text. Specifically, a post comprises a photo (reference 206) of the companion animal and accompanying information (reference 207) provided by the user who created the post The information 207 could include details like the pet's name, description, last seen location, or any notes entered by the user. Above the photo 206, an information bar indicates what kind of post is being viewed. For example, if the post is a scan post, the interface will label it as suchthis may be done via a text label or indicator (denoted by 203, indicating Scan Post) and/or a special icon 202 signifying a scanned microchip post. If the post is a lost post, the information bar will similarly indicate Be On the Look Out (BOLO) for a Lost Post (reference 208). The species or type of the animal is also shown as an icon 204 (for instance, a dog silhouette if the pet is a dog, or a cat icon for a cat) in the post header. Additionally, if a lost post later gets updated to show that the pet has been reunited with its owner, an icon 205 will be displayed to denote that the animal has been returned home. This way, users scrolling through the feed can immediately distinguish scan posts from lost pet reports, identify the type of animal, and see the status of each lost pet report.

[0024] Below the photo 206 in each post entry, the app provides an interactive action bar (reference 215) with multiple buttons that allow users to engage with the post. These post-specific action options include: a Locate button (210), which when tapped will show the location associated with the post (for example, opening a map to display where the scan took place or the area where the pet was lost); a Contact button (211) that enables the user to get in touch with the person who created the post (e.g., initiating a secure in-app message or an email, without immediately revealing personal contact info); a Save button (212) to bookmark or favorite the post for later reference; a Share button (213) to share the post's details with others (for instance, via social media or text message); and a Comment button (214) which allows users to comment on the post or discuss it within the app. The feed interface also provides a filter function (220) to help users manage which posts are visible. By tapping the filter button 220, a user can filter the feed by various attributesfor example, showing only scan posts vs. lost posts, or filtering by proximity or date. This filtering feature makes it easier to find specific types of information in a crowded feed.

[0025] The mobile app's global navigation is represented by a main navigation bar (reference 216), which is typically present at the bottom of the app interface. The main navigation bar 216 allows the user to switch between different primary sections or tabs of the application. For instance, from this nav bar the user can quickly initiate a new scan operation by tapping the Scan button (218). Selecting this Scan button 218 takes the user to the scan interface (as illustrated in FIG. 3) and powers on or connects to the scanning device to read a pet's microchip. Likewise, the navigation bar includes a Map button (219) that the user can tap to open the map view of the system. By tapping the Map button 219, the user is brought to a map screen (see FIG. 5) where all nearby posts are displayed geographically, and where the user can search for posts by microchip ID or view the locations of recent scans. In summary, FIG. 2's interface shows the home/feed screen 217 with its list of posts (200, 201) and associated indicators (202-205, 208) and controls (210-214, 220), while also highlighting the presence of the main navigation bar 216 (with buttons 218 and 219) for accessing other parts of the application. This cohesive interface is designed to let users view community-shared pet information and take actions (locate, contact, share, etc.) to help reunite lost pets with their owners directly from the feed screen.

[0026] Scanner Connection and Scan Process (FIG. 3 & FIG. 6): When the user is ready to scan a found animal, they use the scanning interface of the app. FIG. 3 shows a screenshot of the scan screen 300 in the mobile application. On this screen, the app guides the user to connect to the scanning device 103. For example, a Connect button 301 is provided-when the user taps this button, the app initiates a pairing process with the scanner's microcontroller 104. If the scanner 103 is to be used in handheld mode via a wired connection (as described earlier), the user would attach the scanner physically to the phone using the magnetic connector 305 before tapping the connect button. In the case of a wireless scanner connection, tapping the connect button might prompt the app to search for available scanner devices (e.g., via Bluetooth) and establish the link. Once the application confirms that the scanner 103 is connected and ready (for instance, the scanner might send an acknowledgment or its status to the app), the user can activate the scanner to read a nearby animal's microchip.

[0027] It should be noted that FIG. 3 also conceptually illustrates the phone-scanner attachment. In the depicted embodiment, the scanning device 103 is powered through the smartphonethe power source 302 (the phone's battery/port) supplies energy to the scanner's circuitry 304 via the connector 305. This allows the scanner to operate without its own bulky power supply when in handheld use. (In other embodiments, the scanner 103 could have its own battery and communicate wirelessly, eliminating the need for a physical attachment; both approaches are within the scope of the invention.)

[0028] For the passive scanning scenario with the freestanding unit, FIG. 6 shows an example interface for connecting and managing that setup. In FIG. 6, the mobile application 111 is used to interface with a stationary Totem scanner unit. The app may display a list of available freestanding scanners (e.g., detected via Bluetooth or listed via a server if the units are network-connected), and allow the user to select one to connect. The interface could show the status of the chosen unit and provide controls (if needed) to configure or activate it. For instance, a user might use FIG. 6's screen to initiate a remote scan or to put the unit in a certain mode. In one embodiment, once connected, the app simply listens for datathe freestanding unit will automatically send a notification to the server and app when it scans a microchip. FIG. 6 thus provides a way for users to include autonomous scanners in their network and be notified of passive scan events through the same mobile application.

[0029] Post-Scan Data Entry (FIG. 4): After a successful scan (whether active or passive), the system records the microchip ID and relevant context. FIG. 4 illustrates a screen that is displayed on the mobile app once the scanning device 103 has read an animal's microchip ID. In this post-scan interface, the microchip unique identifier 102 is prominently shown (for example, as a read-only label or in a dedicated field) on the screen. The application then allows the user (the finder) to enrich this data before sharing it. As shown in FIG. 4, the user can enter a descriptive label or name for the animal, using a text input field (e.g., field 402, labeled Pet Name or similar in the UI). The microchip ID itself may also be displayed as a non-editable field or confirmation (label 401 in the figure). The user is further provided with an opportunity to add additional information: a notes or description field 403 allows input of any relevant details (such as the animal's condition, collar details, etc.), and an image upload interface 404 enables the user to attach one or more photos of the animal. The application automatically captures the location of the scan, and FIG. 4 shows a small map 405 or location indicator on the screen representing where the scan took place. This geolocation is obtained via the smartphone's GPS or from the stationary unit's configured location.

[0030] Once the user has optionally added notes and photos, they can save this record, effectively creating a scan post. The scan post contains the microchip ID (with location and time) and any user-provided metadata like notes or pictures. When the user saves/shares it, the post is transmitted via the network 112 to the backend server 118 (through API 116) and stored in the central repository/database 114. At this point, the scan post becomes visible to other users of the system. For example, pet owners searching for their lost pet could see that a pet with a given microchip was scanned at a certain location.

[0031] Lost and Found Posts; Data Management: The platform does not rely solely on scanning. Users can also manually share information about lost or found pets. A pet owner who discovers their pet is missing can create a lost post using the application 111. This typically involves entering the pet's details such as name, species/breed, last seen location, and crucially the microchip unique identifier 102 (if known from their vet records or microchip certificate). They may also include their contact information and a reward offer 209, if desired. Similarly, if someone finds an animal but cannot scan it (e.g., they do not have the scanner device handy or the animal evades capture), they can create a found post. In a found post, the user might input a description of the animal, upload photos, and specify where it was seen or found. They might leave the microchip ID field blank or unknown if not available. Both lost and found posts are also stored in the repository 114 and shared with the user community, much like scan posts.

[0032] All posts, once in the database 114, are accessible to users through the app. The application 111 may present a feed of recent posts (lost, found, scan) or allow searching and filtering. As noted earlier, all users with the app have appropriate access to view shared posts, except for any private data which is kept secure. (The database can have secure segments for personal account information 113 linked to each user, which are not exposed publicly).

[0033] Matching and Notifications: A significant feature of the system is automatic matching of microchip IDs between posts. The backend server 118 continually or periodically checks for cases where a microchip ID in one post corresponds to the same ID in another post. If a match is foundfor instance, a microchip ID 102 recorded in a scan post matches the microchip ID in a lost postthe system will trigger a notification to the relevant users. In this example, the finder who performed the scan, and the pet owner who reported the loss, would both be notified through the application (and optionally via email or SMS through cloud service 117). The notification might alert them that a potential match has been found between a lost pet and a found pet scan, and it will typically include key details: the time of the scan, the location (often presented as a map pin or address) where the pet was scanned, and information on how to reach out to the other party.

[0034] To facilitate a safe and effective communication, the application enables direct messaging between the involved users within the platform. For example, when a match occurs, the owner and finder can open a chat interface in the app or receive contact requests. This approach allows them to discuss and coordinate the pet's return without immediately disclosing personal contact information such as phone numbers or email addresses. (In other words, the app acts as an intermediary; the users can communicate through in-app messages or calls initially.) Only if both parties agree to exchange direct contact details, or once they establish trust (e.g., the owner confirms specific details about the pet or provides proof of ownership), would personal contact info be shared. This privacy-conscious design is supported by the system's workflowfor instance, the microchip ID itself is obfuscated by default in posts visible to others, ensuring that only a hashed or partial representation is shown until a legitimate match is found, at which point the system uses the full ID internally to link records. By matching on an obfuscated value and mediating communication, the platform helps validate each party's connection to the animal while preserving privacy and security for users.

[0035] Map-Based Search (FIG. 5): In addition to automatic matching, the system provides tools for manual searching and visualization of data. FIG. 5 shows a map interface 500 in the application, which helps users locate scan events or posts geographically. A user can enter a microchip ID (or other search parameters) into an input field 501 on this screen. The application will then filter and display on the map any posts associated with that identifier. For instance, if a pet owner inputs their missing pet's microchip number and that pet was recently scanned by someone, the map 500 will zoom to the location 502 of the most recent scan for that microchip and highlight it (for example, with a pin or marker). The user can tap on the marker to get more information about that scan post (time, finder's notes, etc.). The map view also allows browsing of all nearby posts: by default, it might show all lost, found, or scan posts in the vicinity, giving community members a visual way to see if any unfamiliar animals have been reported in their neighborhood.

[0036] Through the combination of these interfaces-list views, scan workflow, and map viewthe application 111 enables users to seamlessly contribute data (when they find an animal) and retrieve data (when they lose an animal or want to help) within the same ecosystem. All user interactions (scans, posts, searches) tie back into the central repository 114 and server logic, which coordinate the information flow and matching.

[0037] Additional Implementation Details: The detailed description above focuses on a particular embodiment of the invention. It should be understood that various modifications and alternative configurations can be employed without departing from the spirit of the invention. For example, the scanning device 103 could be integrated into other form factors (such as a vehicle-mounted scanner or a drone-based scanner) to extend coverage. The communication between the scanner and the application could utilize different protocols, and the server's matching algorithms could incorporate additional criteria (such as time windows or machine learning image matches of pet photos). The user interface layouts shown in FIGS. 2-6 are exemplary; the actual app could have a different design (for instance, the map and list could be combined, or voice alerts could be used to notify of matches). The invention may also support additional features, like social sharing of posts to external networks or integration with veterinary clinic systems, as optional enhancements.

[0038] Throughout this description, references to specific elements (such as scanning device 103, microchip ID 102, etc.) should be understood in the context of the illustrative embodiment of FIG. 1. These references are not intended to restrict the invention to a particular hardware component or numeric designation. Likewise, method steps and user actions described (e.g., tapping a button, adding a photo) are examples of how a typical interaction may occur; equivalent actions (such as voice commands to initiate a scan, or automatic background scanning by the unit) could be substituted.

[0039] In sum, the described system provides a comprehensive solution for pet recovery, combining hardware (multi-mode microchip scanners) and software (networked applications and databases) to bridge the gap between lost-and-found social networks and official microchip identification databases. By reading a pet's microchip in the field and instantly linking that data with a cloud platform where pet owners and finders converge, the invention greatly increases the likelihood of timely and successful reunions of lost pets with their owners. All these features and variations are intended to be covered by the following claims, as would be understood by those skilled in the art.