WO2019168783A1 - System and method for securely transferring ownership of wireless tags - Google Patents

Abstract

Ownership of wireless tags can be managed through a mobile application coordinating with a cloud service-based transaction management system. Tag ownership can be transferred and recorded between two users using mobile devices with different levels of security and context restrictions to accommodate different applications.

Description

SYSTEM AND METHOD FOR SECURELY TRANSFERRING OWNERSHIP OF

WIRELESS TAGS

CROSS REFERENCE TO RELATED APPLICATION

[0001] This application claims the benefit of U.S. Provisional Pat. Appl. No.

62/635,709, filed on February 27, 2018, incorporated herein by reference as if fully set forth herein.

FIELD OF THE INVENTION

[0002] The present invention generally relates to the field(s) of managing transactions of wireless tags. More specifically, embodiments of the present invention pertain to computer-implemented methods for securely transferring ownership of wireless tags between users using mobile computing devices.

DISCUSSION OF THE BACKGROUND

[0003] Wireless near field communication (NFC) and radio frequency (RF) security and/or identification tags are used to digitally track and manage products by their manufacturers and distributors. Such wireless tags are often associated with a product by a manufacturer of the tag, and subsequently shipped to the manufacturer or distributor of the product. Ownership of tags can be assigned to different stakeholders in a commercial context. For example, a tag may be first owned by the maker of the tag, and then later by a merchant who purchases the tag from the tag maker, and so on. In many cases, it is desirable to transfer ownership of tags quickly and without extensive delays, while still doing so securely. The prior art to date does not allow for easy transfers of tag ownership between users in close proximity who would like to exchange ownership securely for an object and associated tag, for instance, between a shipper of a packaged article (with an affixed tag) and a target recipient.

[0004] This “Discussion of the Background” section is provided for background information only. The statements in this “Discussion of the Background” are not an admission that the any particular subject matter disclosed in this “Discussion of the Background” section constitutes prior art to the present disclosure, and excepting for those portions specifically identified as prior art no part of this“Discussion of the Background” section may be used as an admission that any part of this application, including this “Discussion of the Background” section, constitutes prior art to the present disclosure. SUMMARY OF THE INVENTION

[0005] Embodiments of the present invention include the ability to transfer wireless tags between users using different levels of security, and using basic mobile applications running on small portable electronic devices, such as smartphones.

[0006] An aspect of the disclosure concerns a computer-implemented method for transferring ownership of wireless tags in a transfer transaction with a portable computing device, comprising associating a first wireless tag with a first owner for such first wireless tag; in response to a tag transfer request initiated by the first owner during a first transfer transaction, reading the first wireless tag with a reader integrated within a first portable computing device to determine at least a first wireless tag identification code; setting the first wireless tag to a first state corresponding to a wait state in the first transfer transaction; identifying a tap event during the first transfer transaction resulting from placing the first portable computing device within a physical distance sufficient to support near field communication with such first wireless tag; confirming an acceptance indicator provided by the second owner for such first wireless tag as part of such first transfer transaction; transferring ownership of the first wireless tag from the first owner to such second owner after the confirming of the acceptance indicator; and recording the first transaction for the first wireless tag.

[0007] In some embodiments, the first wireless tag is part of a group of wireless tags associated with the first owner, and all of such tags in such group are transferred with a single physical tap as part of the first transaction. When the tag is part of a group of wireless tags associated with the first owner, the tag becomes disconnected from such group. Other restrictions and conditions can be imposed as well. For example, ownership transfer for the first wireless tag can be conditioned on the tag transfer request and the physical tap event occurring in approximately the same physical location. The two portable devices used in the transaction use mobile applications executing on both such devices to coordinate the transfer though a cloud computing service. During the transfer, the wireless tags can be set to the wait state until the transfer is confirmed/accepted. The transaction is preferably recorded at a cloud-based database. Temporal restrictions can be imposed in some instances to detect that both owners have tapped the tag within a certain time/sequence, and require the new owner to claim ownership within a predetermined time/place.

[0008] Various forms of security can also be implemented. In one instance, no further action is required by the first owner of the tag beyond simply designating an intent to transfer, and then allowing a second owner to tap and claim ownership of the tag. In other instances, a push notification can be sent to either/both the first owner/second owner to confirm the transfer. In more restrictive contexts, either or both the original owner and new owner can be required to provide further credentials, preferably in the form of additional secure key tags, prior to authorizing the transfer.

[0009] In preferred embodiments, the wireless tag is a flexible electronic tag printed with an electronic ink, and adapted in a continuous low power mode to respond to a near- field-communications (NFC) interrogation signal. The tag preferably includes a non- alterable non-volatile memory data fields identifying at least a manufacturer ID and a product ID.

[0010] Another aspect of the invention concerns a computer-implemented method for transferring ownership of wireless tags in a transfer transaction with a portable computing device, comprising creating a first entry in a tag ownership database associating a first wireless tag with a first owner, such entry further including a pointer specifying one or more web resources associated with such tag by the first owner; in response to a tag transfer request initiated by the first owner during a first transfer transaction within a mobile application, reading the first wireless tag with a reader integrated within a first portable computing device to determine at least a first wireless tag identification code in a first physical tap event; processing a user identification code and password provided by the first owner with the mobile application at a cloud computing system to generate a first verification confirming the first owner's rights to transfer rights in the first wireless tag; setting the first wireless tag to a first state in the tag ownership database corresponding to a wait state in the first transfer transaction in response to the first verification; generating and communicating a first push notification confirmation to the first portable computing device to confirm the first transfer transaction from the first owner; confirming a second physical tap event during the first transfer transaction resulting from moving the first portable computing device proximate to such first wireless tag; in preferred embodiments, the second physical tap event is confirmed based on processing separate first and second sense signals detected at both the first portable computing device and the second portable computing device, respectively; generating and communicating a second push notification confirmation to the second portable computing device to confirm the first transfer transaction from the first owner; confirming an acceptance indicator provided by the second owner for such first wireless tag upon confirming the second physical tap event; transferring ownership of the first wireless tag from the first owner to such second owner after the confirming of the acceptance indicator; and recording the first transaction for the first wireless tag in the tag ownership database, so as to associate the second owner as the current owner of such tag.

[0011] Still another aspect of the invention covers a computer-implemented method for transferring ownership of wireless tags in a transfer transaction using a first portable computing device and a second portable computing device, the method comprising initiating a tag transfer request by a first owner of a first wireless tag using a graphical user interface (GUI) of the first portable computing device, the first owner being associated with a first user identification code; specifying a tag transfer mode to be used for a tag transfer transaction within the GUI, including at least a non-secure mode, and at least one secure mode; reading the first wireless tag with a reader integrated within the first portable computing device to determine at least a first wireless tag identification code; and communicating the tag transfer request through a network to a server computing system, which tag transfer request includes both the first user identification code and the first wireless tag identification code, where preferably in response to the first owner specifying the non-secure mode, the first wireless tag can be claimed by a new owner to consummate the tag transfer transaction without further confirmation or input by the first owner, and in response to the first owner specifying the at least one secure mode, the first wireless tag can be claimed by a new second owner to consummate the tag transfer transaction only through a push confirmation presented in the GUI by the server computing system.

[0012] Another aspect of the invention covers a computer-implemented method for transferring ownership of wireless tags in a transfer transaction comprises using a cloud computing system to manage and control such transfers by associating a first wireless tag with a first owner; processing a tag transfer request initiated by the first owner during a first transfer transaction, which tag transfer request specifies at least a first wireless tag identification code and a first transfer mode; verifying the first owner and the first wireless tag identification code for the first transfer transaction; setting the first wireless tag to a first state corresponding to a wait state in the first transfer transaction based on verifying the first owner and the first wireless tag identification code; and based on the first transfer mode, performing a corresponding confirmation operation, including pushing a first acceptance indicator to a target second owner for the first wireless tag based on a first transfer mode being identified as a non-secure mode; pushing a second confirmation indicator to the first owner for the first wireless tag based on a first transfer mode being identified as a secure mode; transferring ownership of the first wireless tag from the first owner to the second owner after the confirming of the first acceptance indicator or the second confirmation indicator; and recording the first transaction for the first wireless tag.

[0013] Yet another aspect of the disclosure is directed to computing systems, computer programs, and portable devices implementing the above functions.

[0014] These and other advantages of the present invention will become readily apparent from the detailed description of various embodiments below.

BRIEF DESCRIPTION OF THE DRAWINGS

[0015] FIG. 1 is a diagram of an exemplary cloud-based tag management system enabling a service provider to, among other functions, coordinate tag creation, tag transfers, tag transactions, tag product assignments, tag marketing, etc. for and between manufacturers, merchants and end users in accordance with the teachings of the present disclosure;

[0016] FIG. 2A is a diagram of an exemplary cloud-based Product

Manufacturing/Tag Computing Support system enabling a manufacturer to create and manage tags in connection with product manufacturing operations in accordance with the teachings of the present disclosure;

[0017] FIG. 2B is a diagram of an exemplary cloud-based Tag Manufacturer/Service

Provider Computing Support system enabling a tag service provider to manage and coordinate tags for manufacturers, merchants and end users in accordance with the teachings of the present disclosure;

[0018] FIG. 2C is a diagram of an exemplary cloud-based Merchant Product/Tag

Computing Support system enabling a merchant to manage tags, products, etc. in connection with product marketing and sales operations in accordance with the teachings of the present disclosure;

[0019] FIGs. 3A - 3F are diagrams and flowcharts depicting the structure and operation of exemplary tags in accordance with one or more embodiments of the present invention;

[0020] FIG. 4A is a diagram of exemplary hardware and software employed in a mobile computing device implemented as a Tag User Computing Support system enabled with tag management functions in accordance with one or more embodiments of the present invention;

[0021] FIG. 4B depicts an exemplary graphical interface of a mobile computing device enabled with tag management functions in accordance with one or more embodiments of the present invention;

[0022] FIG. 5A is a diagram of an exemplary cloud-based system enabling transfer of tag ownership within a mobile computing device for an end user in accordance with the teachings of the present disclosure; and

[0023] FIG. 6 is a flow chart showing exemplary methods for transferring ownership of tags with a mobile computing device for an end user in accordance with embodiments of the present invention.

DETAILED DESCRIPTION

[0024] Reference will now be made in detail to various embodiments of the invention, examples of which are illustrated in the accompanying drawings. While the invention will be described in conjunction with the following preferred embodiments, it will be understood that the descriptions are not intended to limit the invention to these embodiments. On the contrary, the invention is intended to cover alternatives, modifications and equivalents reasonably understood by persons of ordinary skill in the art to be included within the spirit and scope of the invention. Furthermore, in the following detailed description, numerous specific details are set forth in order to provide a thorough understanding of the present invention. However, it will be readily apparent to one skilled in the art that the present invention may be practiced without these specific details. In other instances, well-known methods, procedures and components have not been described in detail so as not to unnecessarily obscure aspects of the present invention. Furthermore, it should be understood that the possible permutations and combinations described herein are not meant to limit the invention. Specifically, it will be understood by those skilled in the art that variations that are not inconsistent may be mixed and matched as desired.

[0025] In the context of this application, some additional guidance is provided for particular terms used herein to better appreciate the scope of the invention. As used herein the term“signal” refers to any known structure, construction, arrangement, technique, method and/or process for physically transferring data or information from one point to another. Unless indicated otherwise from the context of its use herein, the terms “information” and“data” may be used interchangeably, although each term is generally given its art-recognized meaning. Furthermore, unless indicated otherwise from the context of its use herein, the terms“coupled to,”“connected to,” and“in communication with” (and grammatical variations thereof) may be used interchangeably and indicate both direct and indirect couplings, connections and communications, but each term is also generally given its art-recognized meaning. Unless indicated otherwise from the context of its use herein, the terms“known,”“fixed,”“given,”“certain” and“predetermined” generally refer to a value, quantity, parameter, constraint, condition, state, process, procedure, method, practice, or combination thereof that is, in theory, variable, but is typically set in advance and not varied thereafter when in use.

[0026] The term "wireless tag" (or simply "tag") as used herein preferably refers to near-field communication (NFC), radio frequency (RF), high frequency (HF), very high frequency (VHF), or ultra high frequency (UHF) tags. The mobile or portable device may comprise a smart phone configured to communicate wirelessly with the wireless tags. The tags may be associated with a user account using a customized tag application on the mobile device.

[0027] In preferred embodiments described herein, the tags are of the NFC type manufactured by Thin Film Electronics ASA (TFEA) in printed integrated circuit (PIC) form (preferably made using TFEA's proprietary printed dopant polysilicon (PDPS) technology) under the tradenames SpeedTap™ and OpenSense.™ In a preferred embodiment, the wireless tags are manufactured using printed doped polysilicon (PDPS) technology (see, e.g., U.S. Pat. Nos. 7,314,513 [Attorney Docket No. IDR0302], 7,485,691 [Attorney Docket No. IDR0422], 8,846,507 [Attorney Docket No. IDR0884], 9,045,653 [Attorney Docket No. IDR1102], and 9,359,513 [Attorney Docket No. IDR1942], the relevant portions of which are incorporated herein by reference).

[0028] A circuit diagram identifying the main components of a preferred example of a tag 300 used in the present embodiments is shown in FIG. 3A. These tags preferably include the following general characteristics:

• Passive (no battery required)

• 13.56MHz operating frequency

• 128 or 256-bit Read-Only Memory (ROM) which is factory programmed and non- electrically modifiable (FIG. 3D).

• 106 Kb/s Data Transfer Rate Manchester bit encoding and OOK load modulation at 847 kHz

• Tag-Talks-First (TTF) Protocol/Mode, meaning the tag preferably transmits its code after it receives enough power from a reader field (FIG. 3E). The tag does not wait for or require and additional commands from a reader before transmitting its code, and for security reasons, preferably does not acknowledge/recognize any commands from the reader

• Adheres to Subset of IS014443A

• 16 bits CRC for data integrity verification

• Operating Range of a Few Centimeters to enable Tap event detection (depends on field strength, antenna design, etc.)

• Single-tag mode for precise one-on-one interaction

[0029] Additional details may be found in datasheets published by TFEA for its tag products, including in materials identified as Thinfilm NFC Barcode Protocol for NFC OpenSense™ & NFC SpeedTap™ Tags available at the manufacturer's website as of the date of filing of this application and incorporated by reference herein.

[0030] As seen in FIGs. 3B, 3C and 3E, these types of tags preferably comply with the NFC Barcode protocol, a common NFC protocol supported by top-tier NFC controllers from NXP, Broadcom, Samsung, Sony, Toshiba, and others. The tags are preferably passive, l28-bit NFC tags operating at l3.56MHz and using a Tag-Talks-First (TTF) protocol. These types of NFC tags operate preferably in a read-only mode to transmit l28-bit codes to NFC- enabled devices, such as phones, tablets, PCs, and set-top boxes. Preferably, the data in the tags is also primarily stored in permanent, unalterable read-only memory but may in some embodiments include a number of reprogrammable dynamic bits to reflect the status of connected or integrated sensors and other information that could change over time. Because these types of tags do not receive information via RF, all data transmissions are unidirectional, from tag 300 to reader 310.

[0031] The NFC SpeedTap and NFC OpenSense tags also preferably store data following the NFC Barcode data formats (previously known as the Kovio NFC Barcode data formats). These are standardized representations of data so that operating systems and applications can consistently interpret the l28-bit data stream. An example of a memory map 330 preferably used by such tags is shown in FIG. 3D. As seen in FIG. 3D the tags preferably include dedicated fields for such parameters as a manufacturers ID field 332, a data format specifier field 334, a data payload field 336 and a CRC field 338.

[0032] In a preferred embodiment, the l28-bit code 330 includes an 8-bit (l-byte)

Manufacturer ID field 332 consisting of a start bit and a 7-bit ID. Under current standards, when implementing a Tag-Talks-First (TTF) format of an NFC Barcode, it is typically required that the first bit is set to‘ to serve as an identifiable start bit for an NFC controller that is atempting to read the tag. A 7-bit manufacturer ID (based on the least significant 7 bits of the manufacturer IDs specified in the ISO/IEC 7816-6 specification) follows the standard logical‘G start bit. An 8-bit (l-byte) data format identifier field 334 then describes how an NFC reader should interpret the contents of the payload field 336. The data format identifier preferably contains two sections: Reserved bits and a Data Type Format. In one preferred embodiment, the 3-bit Reserved section is set to‘000’ for a l28-bit NFC Barcode. A 5-bit Data Type Format allows for 32 possible data types. The data payload field 336 is preferably 96 bits, and may include separate components such as a tag ID 336a, an object/item ID 336b and a vendor ID 336c or some other convenient format for the application in question. The payload 336 can be used for any number of data purposes including for identifying a uniform resource locator (URL) having different formats, an electronic product code (EPC) or any other desired identification/metadata information. The CRC field 338 can be coded in accordance with any number of conventional specifications as needed to support a particular application. In preferred embodiments described herein, the tag identification codes are assigned to products in accordance with the teachings of U.S. Pat. Application No. 15/904,178, also assigned to the present applicant, and hereby incorporated by reference. Again, it should be understood that other NFC Barcode data formats can be used in other applications, and as standards for tags evolve, it is expected that other variations will be employed in the future.

[0033] As seen in FIGs. 3B and 3C when placed proximate to such that it can communicate with an NFC compatible reader 310 (see FIG. 3B) the tag (initially in a sleep mode) transmits after a wake-up time (typically 5ms) in the presence of a sufficiently large interrogation field. As used herein, a "tap" or "tapping event" refers to the transmission of the NFC code by the tag when it is sufficiently close to be read by an NFC controller as may be embodied in a portable computing device (e.g. smartphone). Those skilled in the art will appreciate that the term "tap" in this instance does not require physical contact or bumping of the tag, but, rather, merely waving or placing the reader in close proximity to the tag. The distance range of detectable taps or tapping events can be adjusted of course, by altering field strength, reader antenna size and other physical/transmission parameters. As seen in FIGs. 3C and 3E, the tag continues, at a predetermined interval and standardized protocol, to re transmit the entire length as long as the NFC Barcode is powered up in the reader’s field. The transmission intervals are separated by sleep cycles, which timing periods are again predefined according to an operating standard used in the particular application.

[0034] In addition to other applications, wireless near field communication (NFC) and radio frequency (RF) security and/or identification tags can be used by manufacturers, distributors and other entities to digitally identify, track and manage products and other objects. The term "owned" in connection with a tag means generally that it is associated with a user account by the manufacturer of the tags before receipt by the user (e.g., a product manufacturer, distributor, reseller, packager, end user [consumer], etc.). The term "give away" refers to tags that are not pre-associated with a user account, and may be associated with a user account by the user of the mobile device. Give-away tags may be given away at conferences or demonstrations or as samples, or may be sold as a commodity item.

[0035] The term "group" when used herein preferably refers to tags manufactured on a common roll or sheet, and/or which have at least some common manufacturing ID 332 (FIG. 3D) data, payload data 336, etc. It will be understood that in some embodiments, tags which have different physical tag ids 330 may nonetheless be logically associated to create groupings at different logical levels by the support software described herein.

[0036] Note that in the present disclosure, like numbered structures/steps in the drawings are intended to reference the same or substantially the same structure/step in counterpart drawings.

Tag Management System Architecture

[0037] FIG. 1 is a diagram of an exemplary cloud-based tag management system 100 enabling a service provider to, among other functions, coordinate tag creation, tag transfers, tag transactions, tag product assignments, tag marketing, etc. for and between manufacturers, merchants and end users in accordance with the teachings of the present disclosure. The tag management system 100 preferably includes a front-end cloud computer system 110 and a back-end cloud computing system 170 connected through a secure connection 114. The system 100 further preferably includes separate computing support systems for the different tag stakeholders, including a Product Manufacturing/Tag Computing Support system 140 (shown in more detail in FIG.2A) a Tag Manufacturer/Service Provider Computing Support systeml50 (shown in more detail in FIG. 2B) and a Merchant Product/Tag Computing Support system 160 (shown in more detail in FIG. 2C), all of which preferably include respective suitable portal application software to permit interfacing with their corresponding cloud support systems. It will be understood by those skilled in the art that the functionalities of each of these separate systems may be subsumed and/or integrated into the cloud environments 110/170 respectively in different applications. The tag management system further preferably comprises a tag user computing support system for end-users, including consumers, including one or more mobile devices 120 (or conventional PCs) executing a mobile tag manager application 125 (or web portal 126) and connected through both TCP/IP protocol network l05a (preferably the Internet) and a cellular network l05b. Various forms of tags can be managed by system 100 include wireless security tags (e.g., continuity sensing tag 135') a wireless identification tag 135, and other known types.

[0038] The cloud computing systems (110, 170) may provide shared computer processing resources and data to the other devices in the system, and may be implemented using a cloud computing service such as Google Cloud Platform™ or Amazon Web Services™. The computing systems (110, 170) may be implemented using a service model such as software as a service (SaaS). Some or all of the data may be accessed by authorized users, but is protected from access by unauthorized users.

[0039] In the SaaS service model, the tag manufacturer (service provider) applications (e.g., the mobile application 125 or portal application 126) may be partially executed using the cloud computer 110. The tag manufacturer applications are accessible from a support system 150, as well as through various client devices (such as the mobile device 120) through either a web browser or a program (e.g., application) interface. In a preferred embodiment, the various stakeholders, including tag manufacturer, product manufacturers, merchants (distributor, reseller) or end-users do not manage or control the underlying infrastructure in the cloud computer 110 or 170 including any network, servers, operating systems, and/or storage devices. As will be apparent to skilled artisans, FIG. 1 depicts only those components of system 100 critical to understanding the present teachings. Moreover, other components and software modules may be employed in system 100 consistent with the present teachings.

[0040] FIG. 2A is a diagram of an exemplary cloud-based tag manufacturing support system enabling a manufacturer to create and manage tags with a back-end cloud computing system for product manufacturing operations in accordance with the teachings of the present disclosure. System 170 is a back end cloud computing system that includes one or more computing servers 172, product database 178, tag database 179 and related software modules that support manufactures integrating tags with any type of product/object, such as apparel, consumables, household items, pharmaceuticals, or any other commercial article 137 on which a tag 135 or 135' (which can be in the form of a roll, sheet, etc.) can be affixed directly or as part of packaging during a manufacturing process. The product-tag support system further preferably comprises a host computing system 140 (e.g. a PC, smartphone, etc.), typically onsite at the product manufacturer facility, which system further includes a portal application (not shown, but which may take on any number of conventional forms) to permit communications with a cloud system 170, including a manufacturing administrative module 174, a manufacturing interface module 173, and various tag ID management applications in module 177. A manufacturer tag writer/application module 176 controls the application of tags to products/packaging during the manufacture of the articles of interest at a fabrication facility 175. The various software modules of FIG. 2A assist product manufacturers in managing the creation, application and tracking of products including tags.

[0041] A manufacturing admin module 174 provides visualization and configuration tools, including for enabling users to designate particular tag types/IDs for particular products. The tag IDs are provided by a tag manufacturer through an interface module 173 by a service provider, or, in some instances can be generated directly by a tag ID management module 177. Under either scenario, a product manufacturer can maintain separate databases of both tags (M-Tag 178) and products (M-Product 179). The type and form of the data in such databases may be specified in any convenient form most suitable for the manufacturer's particular operations, infrastructure, etc. Since it is conceivable that the same tag or product can be managed and tracked differently by different stakeholders using different data formats and logical identifiers, the nomenclature in FIG. 2A, i.e., M-Prod db 179 and M-Tag dB 178 denotes such distinction. The application of specific tag ids to specific products is controlled and monitored by a module 176 at the product manufacturing facility 175. In this manner, a product manufacturer can maintain an accurate inventory and record of tag/product pairings. This product/tag pairing data 176’ then be shared with other systems as desired, including through an API call or other known mechanisms known in the art. While shown as part of front-end cloud computing system 170, it will be appreciated by those skilled in the art that some or all portions of such modules, databases, interfaces, etc. in FIG. 2A can be implemented as part of host computing system 140 as well.

[0042] FIG. 2B is a diagram of an exemplary cloud-based tag service provider support system enabling a tag service provider to create, manage and coordinate tags for manufacturers, merchants and end users in accordance with the teachings of the present disclosure. A front-end cloud-computing system 110 is accessed by a tag manufacturing (and/or tag service provider) host system 150. As seen in FIG. 2A, tags 135 are manufactured in a tag fabrication facility 138 in the form of rolls, sheets, or other conventional forms. The tags are physically coded during manufacture in accordance with any number of tag identification code types and formats (see, e.g., FIG. 3, 336a, 336b, 336c). System 110 includes specified by a tag management module 156, which is a front end cloud computing system that includes one or more computing servers 112, a tag ID (S-tag) database 158, a tag metadata database 159, a user identification code database 157, and related software modules that support tag creation support and management functions. The type and form of the data in such databases may be specified in any convenient form most suitable for the tag provider's particular operations, infrastructure, etc. As the tag IDs tracked by system 110 may be the same or have different physical IDs than those tracked by system 170, the tag IDs are designated with a (potentially) different dB index (i.e., S-tag as opposed to M-tag).

[0043] The tag manufacturer/provider system further preferably comprises a host computing system 150 (e.g. a PC, smartphone, etc.), typically onsite at the tag manufacturer facility, which system further includes a portal application (not shown, but which may take on any number of conventional forms) to permit communications with a cloud system 110, including a service administrative module 154, a manufacturing interface module 152 which communicates over a secure connection to back-end cloud system 170 and to a merchant support system 160 (FIG. 2C) and a tag management module 156 that comprises various tag ID management applications. A tag engagement module 151 interacts with and coordinates transactions with end-user systems such as seen in FIG. 2D, including through receipt and processing of tap events, user identification information, and related context data from user computing devices. Tag engagement module 151 further generates and provides any necessary responses from system 110 as described further below, including tag AR metadata, enhanced tag secure data, tag ownership transaction details and tag identification codes. The various software modules of FIG. 2D assist product manufacturers in managing the creation, application and tracking of products including tags. While shown as part of front-end cloud computing system 110, it will be appreciated by those skilled in the art that some or all portions of such modules, databases, interfaces, etc. in FIG. 2B can be implemented as part of host computing system 150 as well.

[0044] FIG. 2C is a diagram of an exemplary cloud-based tag merchant support system enabling a merchant to manage tags, products, etc. in connection with product marketing and sales operations in accordance with the teachings of the present disclosure. A front-end cloud-computing system 110 is accessible to a merchant product/tag host system 160. As seen in FIG. 2C, product/tag ID information 176' from one or more manufacturers can be input from a source including a back-end cloud computing system 170 (FIG. 2 A). In the example shown in FIG. 2C, the product is a consumable item (beer) 137, which has an affixed tag (integrated as part of the label). A merchant/vendor can customize additional content for the product, including multi-media data (video, audio, graphics, etc.) 138 which can be presented when the product tag is read as part of an augmented reality (AR) experience discussed further below.

[0045] System 160 includes a combination of hardware and software components that support merchant (retailer/distributor) product-tag marketing, promotions and sales operations, including one or more server computing machines 164, a host computing system

161, and associated databases containing content and index data for tags (R-Tag db 163), products (R-Product db 169), customers (R-Customer db 167) and customized content (R- Custom Content db 167). The type and form of the data in such databases for such entities may be specified in any convenient form most suitable for the merchant's particular operations, infrastructure, etc. System 160 also supports a merchant website 139, which can be configured with product/marketing/sales webpages in any number of styles known in the art and made accessible to web-enabled browsers (including on smartphones) through conventional uniform resource locators (URLs). Resources and control access to system 160 can also be made through secure applications executing on smartphones 16G and similar portable computing devices.

[0046] The tag manufacturer/provider system further preferably comprises a host computing system 161 (e.g. a PC, smartphone, etc.), typically onsite at the merchant facility, which system further includes a portal application (not shown, but which may take on any number of conventional forms) to permit communications with a cloud system 110. Merchant support system 160 further includes a number of software modules, including a merchant (retailer/distributor or Rtag) management module 165 that enables and supports tag creation, tag-product association, tag-content association, and related management/marketing functions attendant to the marketing, promotion and sales of products including physical tags. As the tag IDs tracked by system 160 may be the same or have different physical IDs than those tracked by systems 110/170, the tag IDs are designated with a (potentially) different dB index (i.e., R-Tag, as opposed to S-tag and M-tag).

[0047] System 160 may further include an AR Context Rules module 163 and AR

Device Rendering Logic module 166, which are responsible for identifying, selecting and presenting customized content to end-user devices 120 within a customized application 125 (see FIG. 1) or as part of a customized experience within a browser accessing website 139. In general, AR Context Rules module 163 dictates user, time, place, manner controls and filters, so that, for example, certain content may be presented for a designated product tag ID (i.e. wool sweater) only to selected users meeting certain criteria (i.e. new customers) at particular locations (i.e., designated partner store) at particular times (i.e. in fall months). All of such parameters can be extracted from the end-user's device 121, product tag 135 and other merchant customer information in db 167. Other examples of context controls will be apparent to those skilled in the art, and may be selected/customized on a tag-by-tag, or customer-to-customer basis. Providing similar support is AR Device Rendering Logic module 166, which is responsible for providing appropriate metadata in the right format for the particular desired AR experience on a target device. For example, a merchant may specify that a designated graphics overlay with particular dimensions should be made on a particular portion of a target device (i.e., model A smartphone by brand X). Again, any form of software tools and controls for overlaying, supplementing and augmenting existing media files (e.g., a graphical image captured by a phone) can be used for this module. While shown as a standalone system in FIG. 2C, it will be understood by skilled artisans that part or all of system 160 could be implemented by front end cloud computing system 110 and controlled/managed through portal applications with basic devices 161, 16G and the like.

[0048] FIG. 4A is a diagram of exemplary hardware and software employed in a mobile computing device 120 enabled with tag management functions in accordance with one or more embodiments of the present invention. The device 120 includes a customized CPU 122 for executing mobile applications, a memory 123 (which may take different forms, including volatile DRAM/SRAM and non-volatile EEPROM), a set of different types of sensors 124 (camera, microphone, touch, gyroscopic to name a few) for capturing different physical stimuli, a Universal Integrated Circuit Card (UICC) or SIM card 126 for communicating over a cellular channel (such as a carrier network 105), Bluetooth/GPS and WiFi communication circuits 127, and various I/O circuits, including display, speakers, etc. Most usefully, as concerns the present disclosure, a mobile computing device includes one or more Near Field Communication (NFC) support circuits, including an NFC communications IC l2la, an associated Secure Element l2lb and an NFC receive/transmit antenna l2lc. Device 120 further includes a number of firmware and software components, including an Operating System (OS) l25a (e.g., Android, IOS), a web/network software interface l25b (e.g., Safari, Chrome, etc.) for establishing communication sessions over an IP network channel l05a (e.g. Internet) and one or more software applications l25c executing on the device and enabling different functions I/O and computational functions.

[0049] For purposes of the present disclosure, user applications which are of most interest are shown in FIG. 4B which depicts an exemplary graphical interface of a mobile computing device enabled with tag management functions in accordance with one or more embodiments of the present invention. These applications generally include an augmented reality (AR) tagged Item application l29a, an enhanced tag/app application l29b, a tag transfer application l29c, an assign new tag application l29d, and a provision tag application l29e. It will be understood by skilled artisans that other hardware and software components may be included in embodiments of a mobile computing device 120 discussed herein.

Secure Tag Transfers

[0050] As alluded to above, security and/or identification tags can be used by manufacturers, distributors and other entities to digitally identify, track and manage products and other objects. To assist in tracking tags/products, tags may be assigned owners, meaning that it is associated with a user account, which can be assigned by the manufacturer of the tags or another stakeholder. The owners of tags can then assign them to products, ascribe them customized content (including AR content) and so on. Since it may be desirable in some applications to transfer tags between entities, the present disclosure contemplates and describes techniques for performing such transfers quickly, easily and seamlessly. For example, in the case of shipping and receiving a packaged product, the latter may have an associated tag. The shipper may desire to transfer ownership of both the product and the tag to a recipient upon delivery through a simplified, efficient exchange process. In contrast to prior art approaches, the present disclosure permits the owner of a tag to transfer ownership with a few simple taps and touch selections within a mobile application interface. A delivery person, for example, can simply tap an application on their mobile device, and within a few seconds a recipient/new owner can confirm receipt on their own mobile device equipped with a counterpart application. The process is simple, intuitive, and expedient. As the bulk of the transactional authentication and recording is performed remotely within a cloud computing system, the mobile application can be simpler and with a reduced footprint (storage and computation-wise).

[0051] To prevent mistake or fraud, different types of security can be incorporated into a tag transfer process. For example, it may be useful to confirm or require that both the transferor and transferee (or assignor/assignee) of a tag have provided legitimate user identifications, are in the same location (i.e. using geofencing), or that they perform a transfer within a certain period of time, etc. Other forms of securing will be apparent to those skilled in the art.

[0052] FIG. 5A is a diagram of an exemplary cloud-based system 500A enabling mulit-modal transfer of tag ownership within a mobile computing device for an end user in accordance with the teachings of the present disclosure. In a preferred embodiment, a first mobile device 520 can transfer ownership of tags 535 on a product 537 to a second mobile device 520' using a mobile application 522. As seen in FIG. 5A, a first user/owner of a tag 535 (or a set of tags 536) invokes application 522 and can simply tap on the tag to initiate a transfer. The user has three different possible transfer modes as explained below and shown in FIG. 5A with different shading, including a basic mode, and two different secure modes, including a secure confirmation mode, and a secure transfer mode. In a first basic mode, the transfer request 526a, including the tag ID(s) and other related context information, including user/device ID, location information, etc. can be sent along with the request to front end cloud computing system 110. The inclusion of multiple tags 536 as part of the transfer can be effectuated using the techniques noted above with respect to tag assignments, i.e., by selecting a range of tags, a beginning and end tag, etc. The second user then activates a similar application 522, and taps/selects the tag(s) 535/536 to take ownership of the same. This causes the application to communicate an acceptance 526b of the transfer of the tag to front end cloud computing system 110. This acceptance 526b preferably includes a set of tag IDs, a second user ID, and other context information, including location data. The cloud computing system then matches the transfer/acceptance requests for the tag(s) in question, and records the new ownership. In some instances, the location data can be used as a verifying parameter for the tag transfer as well, i.e., to confirm that both the prior and current owner are in the same location.

[0053] In secure transfer modes, additional verification layers can be employed. For example, in a first secure mode, the existing owner can be specifically given a prompt 526c to confirm the transfer. Only after providing a confirmation does the transfer in ownership become registered. In a second secure transfer mode, both users are required to provide additional identification information, including one or more of a password, or even information from additional unique customized key tags 526d and 526e, that must be tapped as part of the transfer. This is depicted in FIG. 5A by the requirement of both a 3rd and possible a 4th tap on respective transferor and transferee key tags 524 and 524'. On the server side, and with reference to FIG. 2B, tag engagement module 151 and tag management module 156 coordinate and handle the transfer transaction, updating database 158 as needed to reflect the change in ownership of the tag(s).

[0054] FIG. 6 is a flow chart showing exemplary methods 600 for transferring ownership of tags with a mobile computing device for an end user in accordance with embodiments of the present invention. As noted above, the present disclosure advantageously provides at least three different modes for transferring ownership of tags which can be used in different applications depending on security requirements.

[0055] At step 602, a user may elect to have his/her tag app and/or device registered at cloud system 110. At step 601, the first user/tag owner indicates that they want to transfer one or more tags, and specifies a particular mode to be used. At step 606, a user tap on a tag is detected by device 620 in the manner described above in connection with FIGs. 3A-3F. The tag ID (included in some or all of payload 136) is then extracted and read at step 610.

[0056] Step 612 processes whether the user is transferring a single tag or a group of tags. For example, in a group of tags (a roll or sheet) with unique IDs a transferor may select a beginning tag and ending tag, and so on, so that all tag IDs in between are included in the transfer; alternatively, they may be specified manually as a range of tag IDs. When only a single tag is selected, it is removed from the group at step 614. After the tag ids are determined, they are confirmed/verified at step 621, along with a user id (which may be any one or more of a username, password, or application registration ID) by checking a database at step 630, to determine for example if the user is indeed the current owner of the tag. Location data can also be derived from the application and device sensors (i.e. GPS and similar techniques). The tag and UID databases (FIG. 2B, databases 157/158) are consulted as part of step 630.

[0057] When the transfer request is validated the tags are set to a conditional, ready to transfer state at step 670. At step 672, the target recipient is prompted to confirm transfer of the tag(s) in question. In some instance an acceptance confirmation from a new prospective tag owner can be accepted in parallel (after receiving the second tap event noted above) and then matched up against the pending transfer request based on a tag ID. If a non-secure mode is identified at step 674, the process proceeds to then formally record and transfer ownership of the tag(s) in question to the new owner at step 690. This information is then used to update the tag ID/UID databases discussed for step 630. [0058] When a secure mode is identified at step 674, a further determination is then made based on the mode selected. In the event of a secure mode 1 election by the user, the transferor/current owner is prompted for a confirmation at step 676, as a condition for consummating the transaction. After receiving and processing the transfer confirmation, the process then picks up with step 690 in the same manner as discussed above. When the user selects a secure mode 2 option, additional parameters are considered for the transaction. In particular, the owner/recipient locations are preferably confirmed at step 680, to ensure that the two entities are in the same (approximate) location (subject to known allowances in positions attendant to the technique employed). When the two are in the same location, their respective key tags are also examined and confirmed at step 682, based on a tap event at step 603, which is used to record a user key tag ID. In the event all available parameters are deemed valid, the process goes on to record details of the transaction, including a sequence, location, etc. at step 684. After that point, the process proceeds as noted earlier, picking up with step 690 in which the ownership records for the tag are updated.

[0059] It will be understood by those skilled in the art that the above descriptions are merely examples and that countless variations of the same can be implemented in accordance with the present teachings. A number of other conventional steps that would be included in a commercial application have been omitted, as well, to better emphasize the present teachings.

[0060] It will also be apparent to those skilled in the art that the modules of the present invention, including those illustrated in the figures can be implemented using any one of many known programming languages suitable for creating applications that can run on large scale computing systems, including servers connected to a network (such as the Internet) as part of a cloud computing system. The details of the specific implementation of the present invention will vary depending on the programming language(s) used to embody the above principles, and are not material to an understanding of the present invention. Furthermore, in some instances, a portion of the hardware and software will be contained locally to a user's computing system, which can include a portable machine or a computing machine at the user's premises, such as a personal computer, a PDA, digital video recorder, receiver, etc.

[0061] Furthermore, it will be apparent to those skilled in the art that this is not the entire set of software modules that can be used, or an exhaustive list of all operations executed by such modules. It is expected, in fact, that other features will be added by system operators in accordance with customer preferences and/or system performance requirements. Furthermore, while not explicitly shown or described herein, the details of the various software routines, executable code, etc., required to effectuate the functionality discussed above in such modules are not material to the present invention, and may be implemented in any number of ways known to those skilled in the art. Such code, routines, etc. may be stored in any number of forms of machine-readable media. It is understood that the protection afforded the present invention also comprehends and extends to embodiments different from those above, but which fall within the scope of the claims presented below.

Claims

CLAIMS What is claimed is:

1. A computer-implemented method for transferring ownership of wireless tags in a transfer transaction with a portable computing device, the method comprising:

associating a first wireless tag with a first owner for said first wireless tag;

reading the first wireless tag with a reader integrated within a first portable computing device to determine at least a first wireless tag identification code in response to a tag transfer request initiated by the first owner during a first transfer transaction;

setting said first wireless tag to a first state corresponding to a wait state in said first transfer transaction;

identifying a tap event during said first transfer transaction resulting from placing said first portable computing device within a physical distance sufficient to support near field communication to such first wireless tag;

confirming an acceptance indicator provided by the second owner for such first wireless tag as part of such first transfer transaction;

transferring ownership of the first wireless tag from said first owner to such second owner after said confirming of said acceptance indicator; and

recording said first transaction for said first wireless tag.

2. The method of claim 1, wherein said first wireless tag is part of a group of wireless tags associated with said first owner, and all of said first wireless tag tags in said group of wireless tags are transferred with a single physical tap as part of said first transaction.

3. The method of claim 1, wherein said first wireless tag is part of the group of wireless tags associated with said first owner, and transfer of said first wireless tag causes said first wireless tag to become disconnected from said group of wireless tags.

4. The method of claim 1, wherein ownership cannot be transferred for said first wireless tag unless said first wireless tag transfer request and said physical tap event occur in approximately the same physical location.

5. The method of claim 1, wherein said first wireless tag transfer request and said physical tap event occur in different physical locations.

6. The method of claim 1, wherein an owner of said first wireless tag can associate one or more URLs with said first wireless tag identification code; and further wherein said one or more URLs are retrieved and presented to a third party user when reading said first wireless tag with a third portable computing device.

7. The method of claim 1, further comprising coupling said first portable computing device and said second portable computing device to a cloud computing system as part of said first transaction.

8. The method of claim 1, wherein said first transfer transaction is effectuated by mobile applications executing on both first portable computing device and said second portable computing device.

9. The method of claim 7, wherein said setting of said first wireless tag to said wait state is performed by said cloud computing system.

10. The method of claim 7, further comprising generating and communicating a push notification confirmation to said first portable computing device as part of said first transfer transaction.

11. The method of claim 10, further comprising completing said first transfer transaction when said push notification confirmation is verified by said first owner with said first portable computing device.

12. The method of claim 1, further comprising specifying an expiration period for said wait state, wherein said first transfer transaction is terminated after said predetermined period if said acceptance indicator is not confirmed.

13. The method of claim 1, wherein said first wireless tag is formatted with non-alterable non-volatile memory data fields identifying at least a manufacturer ID and a product ID.

14. The method of claim 1, wherein said first augmented experience wireless tag comprises a flexible electronic tag printed with an electronic ink.

15. The method of claim 1, wherein said first augmented experience wireless tag is adapted to respond to a near-field-communications (NFC) interrogation signal.

16. The method of claim 1, wherein the first augmented experience wireless tag is configured in a continuous, low power transmit mode.

17. The method of claim 4, further comprising associating a first key tag as identifying said first owner, and associating a second key tag as identifying said second owner, and as part of authorizing said first transaction performing an identification check to determine: i. if said first owner has tapped said their first key tag with said first portable computing device; and

ii. if said second owner has tapped their second key tag with said second portable computing device.

18. The method of claim 1, wherein said recording for first transaction is performed in a tag ownership database.

19. The method of claim 18, wherein a transfer state for said first wireless tag is set to completed.

20. A computer-implemented method for transferring ownership of wireless tags in a transfer transaction with a portable computing device, the method comprising:

creating a first entry in a tag ownership database associating a first wireless tag with a first owner, such entry further including a pointer specifying one or more web resources associated with said first wireless tag by said first owner;

in response to a tag transfer request initiated by the first owner during a first transfer transaction within a mobile application, reading the first wireless tag with a reader integrated within a first portable computing device to determine at least a first wireless tag identification code in a first physical tap event;

processing a user identification code and password provided by the first owner with the mobile application at a cloud computing system to generate a first verification confirming the first owner's rights to transfer rights in said first wireless tag;

setting said first wireless tag to a first state in said tag ownership database corresponding to a wait state in said first transfer transaction in response to said first verification;

generating and communicating a first push notification confirmation to said first portable computing device to confirm said first transfer transaction from said first owner; confirming a second physical tap event during said first transfer transaction resulting from moving said first portable computing device proximate to such first wireless tag, wherein said second physical tap event is confirmed based on processing separate first and second sense signals detected at both said first portable computing device and said second portable computing device, respectively;

generating and communicating a second push notification confirmation to said second portable computing device to confirm said first transfer transaction from said first owner; confirming an acceptance indicator provided by the second owner for such first wireless tag upon confirming said second physical tap event;

transferring ownership of the first wireless tag from said first owner to such second owner after said confirming of said acceptance indicator; and recording said first transaction for said first wireless tag in said tag ownership database so as to associate said second owner as the current owner of such tag.

21. A computer-implemented method for transferring ownership of wireless tags in a transfer transaction using a first portable computing device and a second portable computing device, the method comprising:

initiating a tag transfer request by a first owner of a first wireless tag using a graphical user interface (GUI) of the first portable computing device, said first owner being associated with a first user identification code;

specifying a tag transfer mode to be used for a tag transfer transaction within the GUI, including at least a non-secure mode, and at least one secure mode;

reading the first wireless tag with a reader integrated within said first portable computing device to determine at least a first wireless tag identification code; and

communicating said tag transfer request through a network to a server computing system, which tag transfer request includes both said first user identification code and said first wireless tag identification code, wherein in response to said first owner specifying said non-secure mode, said first wireless tag can be claimed by a new owner to consummate said tag transfer transaction without further confirmation or input by said first owner, and in response to said first owner specifying said at least one secure mode, said first wireless tag can be claimed by a new second owner to consummate said tag transfer transaction only through a push confirmation presented in said GUI by said server computing system.

22. The method of claim 21, wherein said new owner must claim ownership of said first wireless tag within a predetermined time and while within a predetermined area.

23. The method of claim 21, further comprising placing a second portable computing device within a physical distance sufficient to support near field communication to said first wireless tag to permit a new second owner to confirm acceptance of ownership of such tag within said predetermined period.

24. The method of claim 21, wherein a second secure mode is presented in the GUI, which, when selected, requires said first owner to further identify themselves through a separate secure near field communication key tag before completing said tag transfer.

25. A computer-implemented method for transferring ownership of wireless tags in a transfer transaction using a cloud computing system, the method comprising:

associating a first wireless tag with a first owner; processing a tag transfer request initiated by the first owner during a first transfer transaction, which tag transfer request specifies at least a first wireless tag identification code and a first transfer mode;

verifying said first owner and said first wireless tag identification code for said first transfer transaction;

setting said first wireless tag to a first state corresponding to a wait state in said first transfer transaction based on said verifying;

performing a corresponding confirmation operation based on said first transfer mode, including:

pushing a first acceptance indicator to a target second owner for said first wireless tag based on a first transfer mode being identified as a non-secure mode;

pushing a second confirmation indicator to said first owner for said first wireless tag based on a first transfer mode being identified as a secure mode;

transferring ownership of the first wireless tag from said first owner to said second owner after said confirming of said first acceptance indicator or said second confirmation indicator; and

recording said first transaction for said first wireless tag.

26. The method of claim 25, further comprising providing a second secure mode, that when selected by the first owner, requires at least said first owner to provide identification information from a first secure NFC key tag before transferring ownership to said second owner.

27. The method of claim 26, further comprising further requiring said second owner to provide identification information from a second secure NFC key tag before transferring ownership to said second owner.

28. The method of claim 25, wherein said first wireless tag is part of a group of wireless tags associated with said first owner, and all of said first wireless tags in said group of wireless tags are transferred with a single physical tap by the first owner as part of said first transaction.

29. The method of claim 25, wherein said first wireless tag is part of the group of wireless tags associated with said first owner, and transfer of said first wireless tag causes said first wireless tag to become disconnected from said group of wireless tags.

30. A computing system configured for transferring ownership of wireless tags in a transfer transaction comprising: one or more software modules adapted to execute on a portable computing device and/or a cloud-based server system and perform at least the following functions:

associate a first wireless tag with a first owner for such first wireless tag; in response to a tag transfer request initiated by the first owner during a first transfer transaction, read the first wireless tag with a reader integrated within a first portable computing device to determine at least a first wireless tag identification code; set said first wireless tag to a first state corresponding to a wait state in said first transfer transaction;

identify a tap event during said first transfer transaction resulting from placing said first portable computing device within a physical distance sufficient to support near field communication to such first wireless tag;

confirm an acceptance indicator provided by the second owner for said first wireless tag as part of said first transfer transaction;

transfer ownership of the first wireless tag from said first owner to said second owner after said confirming of said acceptance indicator; and

record said first transaction for said first wireless tag.

31. A computer program having executable instructions stored on a non-transitory machine-readable medium on a portable computing device adapted to transfer ownership of wireless tags in a transfer transaction using a first portable computing device and a second portable computing device, the computer program comprising:

one or more software modules adapted to execute on the portable computing system and perform at least the following functions:

initiate a tag transfer request by a first owner of a first wireless tag using a graphical user interface (GUI) of the first portable computing device, said first owner being associated with a first user identification code;

specify a tag transfer mode to be used for a tag transfer transaction within the GUI, including at least a non-secure mode, and at least one secure mode;

read the first wireless tag with a reader integrated within said first portable computing device to determine at least a first wireless tag identification code; and communicate said tag transfer request through a network to a server computing system, which tag transfer request includes both said first user

identification code and said first wireless tag identification code, wherein in response to said first owner specifying said non-secure mode, said first wireless tag can be claimed by a new owner to consummate said tag transfer transaction without further confirmation or input by said first owner, and in response to said first owner specifying said at least one secure mode, said first wireless tag can be claimed by a new second owner to consummate said tag transfer transaction only through a push confirmation presented in said GUI by said server computing system.

32. A cloud computing system adapted to transfer ownership of wireless tags in a transfer transaction comprising:

one or more software modules adapted to execute on computing hardware of the cloud computing system and perform at least the following functions:

associate a first wireless tag with a first owner;

process a tag transfer request initiated by the first owner during a first transfer transaction, which tag transfer request specifies at least a first wireless tag identification code and a first transfer mode;

verify said first owner and said first wireless tag identification code for said first transfer transaction;

set said first wireless tag to a first state corresponding to a wait state in said first transfer transaction based on said verifying;

performing a corresponding confirmation operation based on said first transfer mode, including:

pushing a first acceptance indicator to a target second owner for said first wireless tag based on a first transfer mode being identified as a non-secure mode; pushing a second confirmation indicator to said first owner for said first wireless tag based on a first transfer mode being identified as a secure mode;

transferring ownership of the first wireless tag from said first owner to said second owner after said confirming of said first acceptance indicator or said second confirmation indicator; and

recording said first transaction for said first wireless tag.