ISO15693 Library Desktop Reader Workflow: From Tag to Transaction

An ISO15693 library desktop reader workflow connects a tagged book to a software-managed circulation transaction. The reader identifies the tag and performs supported read or write operations. Connected software associates that information with a library item, applies circulation rules and records the borrowing or return result.

A successful tag read confirms that tag data was received. A completed loan or return requires confirmation from the library application, together with the outcome of any required tag updates.

What the desktop reader does at the library desk

An ISO15693 desktop reader operates at 13.56 MHz and communicates with compatible HF tags. A passive library tag draws operating energy from the reader’s electromagnetic field and responds to commands through its antenna.

At a service desk, the reader provides the radio communication path between book tags and the workstation application. Its operations can include discovering tags, collecting unique identifiers, reading memory and writing permitted data. The available operations depend on the reader, tag and supporting software.

The workstation application and library management system may belong to one software package or separate systems. These responsibilities do not imply a particular software architecture.

ISO15693 library tag identification, step by step

1. Discover responding tags

When a compatible passive tag receives sufficient energy, it can respond to inventory commands. Here, “inventory” means discovering responding tags; it does not mean that the library has completed a stock audit or updated its collection records.

ISO15693 includes anti-collision mechanisms that help resolve responses when several tags are present. The reader can distinguish individual tags and address them for subsequent operations. Several books can therefore participate in one identification session, while communication resolves individual tag responses.

Anti-collision does not guarantee that every book presented has been identified. The application receives the tags that responded successfully, without inherently knowing how many physical books were presented.

2. Collect the tag UID

The UID identifies the tag at the RFID communication level. It is distinct from the library’s item identifier and circulation record.

A library may associate the UID with an item record in software. Another implementation may use a separate item identifier encoded in tag memory. The application must understand the identification method and data format in use.

This explains why a workstation can receive a UID yet display “unknown item.” The radio exchange may have succeeded while the association with a library record is missing or unusable.

3. Read additional data when needed

If the application needs information stored in tag memory, it requests supported read operations. The reader returns the data, and software interprets it according to the library’s encoding arrangement.

Receiving memory bytes and understanding their meaning are separate tasks. ISO15693 support alone does not tell software which bytes identify a library item or how to interpret them.

4. Resolve the library item

The application uses the UID association or decoded item information to locate the library record. That record supplies the context needed for borrowing or return.

Software also needs to handle repeated observations. A book remaining on the reader may be identified repeatedly. Those observations should not automatically become new circulation requests.

How identification becomes borrowing or return

The following sequences describe typical responsibilities. The order of requests and tag updates depends on the integration.

Borrowing

A borrowing session needs item identification and borrower context established by the application. Reading a book tag alone does not identify the borrower or determine borrowing eligibility.

1. The reader reports the tag identification and any requested data.
2. The application resolves the item and submits a borrowing request with the relevant borrower context.
3. The library system applies its rules, such as whether the item can circulate and whether the borrower may borrow it.
4. The system records an accepted loan or returns a rejection.
5. Where required and supported, the application coordinates a tag or security-state update and checks its result.
6. The workstation displays the individual item’s outcome, including any unresolved operation.

A reader’s detection signal cannot establish all these results. The confirmation shown to the user needs to reflect the circulation decision and any required follow-up operations.

Returns

For a return, the reader again supplies tag identification. The application resolves the item and asks the library system to process its return. The system updates the circulation record and may supply further handling information, such as a hold or transfer instruction.

Where required and supported, software also coordinates a tag-state update. A returned item may still need further handling after its circulation record changes, so the workstation should make that distinction visible.

Self-service borrowing and returning require suitable application software, user interaction and transaction handling alongside the reader.

Multiple tags can produce different transaction results

For example, imagine three tags are identified. The library system accepts a loan for the first item, rejects the second because of a circulation restriction, and cannot match the third identification to an item record.

All three tag reads succeeded, but only one loan is complete. An item-by-item result makes this visible. A message saying “three tags detected” cannot confirm that all three books were borrowed.

What writing a library tag changes

Writing changes permitted data or state on a tag. During initial encoding, an application might ask the reader to store an item identifier using the library’s chosen format. Later workflows may require other supported updates.

A successful write requires a supported command, permission to change the target memory or state, and successful communication. Receiving a UID does not establish that all memory is readable or writable. Where appropriate, software can request a subsequent read to verify that the intended data was stored.

A tag write and a library database update are separate operations. Writing an item identifier does not create a loan, and recording a loan does not prove that a requested tag update succeeded.

Some library installations coordinate circulation with tag-based security functions. The mechanism and commands depend on the tags, readers and wider system. ISO15693 support alone does not establish a particular security feature or integration with library gates.

Borrower details and loan history do not have to be stored on the book tag. Software can maintain those records while using the tag to identify the item.

Library RFID reader software integration has three layers

Protocol support

Protocol support concerns radio communication between reader and tag. ISO15693 provides the communication foundation for this workflow.

NFC labeling alone does not establish compatibility. NFC covers different tag technologies; the actual tag protocol and the reader’s documented support must match.

Supported tag commands

Command support determines which operations are available beyond discovering a tag. Memory operations and additional chip functions can differ. The reader’s firmware and host interface must expose the operations the application needs.

A chip manufacturer’s description establishes characteristics of that chip, not the capabilities of every reader communicating with it. Basic identification may work even when a requested write or additional function is unavailable.

Reader and tag documentation establish the supported commands and their conditions. A blanket chip-family compatibility claim cannot replace that information.

Application integration

The host connection carries commands and results between reader and software. The connection alone does not interpret tag data, associate it with library items or supply circulation logic.

Reader interface documentation explains how software requests operations and receives results. Tag encoding documentation explains the data being exchanged. Library application documentation defines how identification becomes a circulation request and how its outcome is reported.

A complete integration therefore needs compatible radio communication, the required tag operations and software that coordinates the library transaction.

Understanding incomplete workflow results

Separating the stages helps staff and integrators understand a problem without treating every failure as an unreadable tag.

A timeout does not prove that the library system made no change. Integration software needs to reconcile the recorded status before treating a retry as a new transaction.

Useful desk confirmation distinguishes the item identified, the circulation decision and any required tag update. Staff and patrons can then see which books are complete and which still need attention.

DO RFID Group

Do RFID is a leading China-based manufacturer with over 15 years of experience. We specialize in customized RFID readers, tags, and cards, delivering high-quality, tailored solutions that meet your unique business needs and drive seamless, efficient identification.