OF TRANSACTIONS FOR A SMART OBJECT

RELATED APPLICATIONS

This application claims the benefit of priority based on U.S. Provisional Patent Application no. 62/475,299 filed 23 March 2017, the entire contents of which are incorporated herein by reference in their entirety as if fully set forth herein.

This application is also related to International Patent Application PCT/IL 2016/000017 and Israel Patent Application 248317, filed 13 October 2016 (hereinafter, the "related applications"), the contents of which are incorporated herein by reference in their entirety as if fully set forth herein.

FIELD OF THE INVENTION

The present invention, in some embodiments, relates to smart object technology, and more particularly, but not exclusively to methods and systems for managing smart objects, including, but not limited to, smart cards, smart objects integrated in mobile devices using Host Card Emulation (HCE) technology or other portable object emulation technology, and other portable smart objects.

BACKGROUND OF THE INVENTION

Smart cards, smart portable objects and other smart objects are well known. For the purposes of this application, the term "smart object" will be used generically to describe any device in which smart card technology is used. A smart object is a personal and portable device associated with a particular individual that includes an embedded integrated circuit that can be a secure microcontroller or equivalent intelligence with internal memory or a memory chip alone. The smart object is connectable to an interface, typically having read/write capability, by direct physical contact or via a remote contactless radio frequency interface. With an embedded microcontroller, smart objects have the ability to store large amounts of data, carry out their own on-board functions (e.g., encryption and mutual authentication) and interact intelligently with a compatible read/write interface, allowing the interface to read from and/or write to the smart object. Smart object technology is available in a variety of form factors, including plastic cards, key fobs, watches, subscriber identification modules used in GSM-connected mobile phones, and USB-based tokens. Smart card technology can also be built into other portable personal devices, such as mobile phones and USB devices, which then themselves become smart objects. Smart phones can also include a module for reading or writing on actual smart cards and other smart objects. Smart objects can be integrated in mobile devices, using Host Card Emulation (HCE) technology or other portable object emulation without the need for a physical card.

Smart objects can provide personal identification, authentication, data storage, and application processing. EuroPay, MasterCard Visa (EMV) compliant credit cards, and the complementary card readers, are widespread. In addition to smart card readers, there are also contactless smart cards that do not require physical contact between a card and reader. It is possible to "read" the data on a contactless smart object using Near-field communication (NFC). NFC is a set of communication protocols that enable two electronic devices, one of which is usually a portable device, such as a smart phone, to establish intercommunication by bringing them within about 4 cm (2 in) of each other. Typical uses of contactless smart objects are for payment and ticketing, include mass transit and motorway tolls.

Conventionally, in order to load data for services, such as a mass transit fare contract, or to pre-pay for a pre-selected quantity of services (i.e., to load or add value to the smart object), it is necessary to take the smart object to an authorized loading location having a compatible read/write interface. Typically, such a loading location include fare vending machines or add-value machines, to physically load the data on the smart object (i.e., record the transaction data and/or instructions the memory of the smart object), one card at a time. Payment, e.g., by charging of a user's credit card or bank account, may take place at the time of loading or in some instances, when a service is actually used. Online options are limited to online payment, with the actual loading onto the card taking place in an authorized machine. If several individuals need to use a particular loading location at the same time, this can be a time-consuming process since it will require all users to queue up in a few select locations to load value to their smart objects, one after the other.

A method and system for remote loading of data or performance of an operation on a smart object is described in detail in Applicant's above-identified related applications. The system includes at least one, and preferably, multiple user interfaces and a central management unit ("CMU"). The user interfaces have access to the Internet and include smart object read/write capability, processors, and universal, (i.e., multi-platform) compatibility software that makes the interface compatible with a variety of smart object operating platforms. The universal compatibility software is described in the related applications, and is referred to there as a "software development kit" (SDK), It will be so-referred to here as well for consistency.

The CMU in the system of the related applications is located in the Cloud, and is configured to be compatible with multiple platforms and to communicate over multiple standards, in two-way communication with each smart object interface via its own embedded SDK. It is also in communication with the backend system of at least one service or product provider from which transactions may be requested by the smart object user. Optionally, the CMU has access to backend systems of multiple such providers.

The CMU also includes a secure encryption unit providing a key for each communication between each SDK and the CMU and a web services managing server configured to provide secure two-way communication between each user interface, the secure encryption unit, the provider backend and the CMU itself.

However, it would also be desirable to have the possibility of pre-ordering a service contract or other transaction, which can then be actually loaded onto the smart object at a later time or date and at one of many easily accessible interface locations. Additionally, it would be desirable to have the option of not loading the transaction on the smart object, but still making it executable on demand of the smart object user, thus dispensing with a need to visit a dedicated loading station. The present invention is directed to meeting this desired objective and which is compatible with multiple communication protocols and with a wide range of smart objects.

SUMMARY OF THE INVENTION

According to an aspect of some embodiments of the present invention, there is provided a method for performing operations on a smart object which comprises receiving from one of a plurality of smart object read/write interfaces, at a central management unit (CMU), a request for a selected transaction for a smart object, receiving from the one read/write interface at the CMU, identification details of the smart object making the request, details concerning the selected transaction and details concerning a source of payment for the transaction, storing the received details of the requested transaction, identification of the requesting smart object, and the payment source in a database accessible by all read/write interfaces compatible with the requesting smart object, subsequently, reading the smart object for which the original request was made at the same or a different interface, identifying the smart object, receiving from the read/write interface with which the requesting smart object is then associated by the CMU, a request to activate the previously selected transaction to the requesting smart object, confirming by the CMU that a transaction for the requesting smart object is stored in the database, if the requested transaction is found, automatically sending information about the previously selected transaction to the interface with which the requesting smart object is then associated whereby the transaction can be executed, and automatically debiting payment for at least part of the previously selected transaction according to the stored payment source details.

According to some embodiments of the invention, the selected transaction is a subscription for a renewable, periodic contract.

According to some embodiments of the invention, the selected transaction is the use of the smart object as an electronic wallet.

According to some embodiments of the invention, at least some of the interfaces are compatible with more than one type of smart object. According to some embodiments of the invention, the interface is responsive to information read from the smart object, or from a manual input device or provided verbally to identify details of the smart object making the request, details concerning the selected transaction and details concerning a source of payment for the transaction.

According to some embodiments of the invention, information received from the interface and information generated by the CMU about the requested transaction is stored in a database in the Cloud.

According to some embodiments of the invention, at least one of the interfaces is a mobile smart phone or a personal computer equipped with an SDK and a smart object reader.

According to some embodiments of the invention, the CMU is operative to receive from a single user, an advance order for transactions for multiple smart objects of the same or different types owned by the user, or on behalf of different owners during a single session, and wherein the ordered transactions may be separately loaded to the smart objects for which they were ordered at a single or different times.

According to some embodiments of the invention, details of an approved preordered transaction are loaded onto the smart object through the then associated interface.

According to some embodiments of the invention, the automatically sent information results in performance of a transaction, but does not result in loading details of the transaction on to the smart object.

According to another aspect of as some embodiments of the invention, there is provided a system for performing operations on a smart object which comprises a CMU server with an associated database including details of a plurality of smart objects and a plurality of users and a plurality of smart object read/write interfaces in communication with the server, the server being operative to receive requests from the interfaces for transactions, the requests including information identifying a smart object for which the request is being made, information identifying the requested transaction, and information identifying a source of payment for the requested transaction and wherein the server is further operative to receive at a later time after the transaction has been requested, a request that the transaction be activated for the smart object for which it was previously requested, to validate the requested transaction, and to send confirming information to the interface allowing the transaction to proceed. According to some embodiments of the invention, the confirming information includes details of the transaction and an instruction to load the details to the smart object.

According to some embodiments of the invention, the confirming information allows at least part of the transaction to proceed, but does not include an instruction to load details of the transaction to the smart object. Unless otherwise defined, all technical and/or scientific terms used herein have the same meaning as commonly understood by persons having ordinary skill in the art to which the invention pertains.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention will be further understood and appreciated from the following detailed description taken in conjunction with the drawings, in which:

Figure 1A is a flow chart illustrating a method for ordering transactions in a conventional smart object in advance of its intended use, in accordance with some embodiments of the present invention;

Figure IB is a flow chart illustrating a method for ordering transactions in a smart object in advance of its intended use, in accordance with alternative embodiments of the present invention;

Figure 1C is a schematic illustration of a system for performing transactions in a smart object, constructed and operative in accordance with some embodiments of the present invention; Figure 2A is a schematic illustration of a system and method for performing transactions using a smart object, according to the above-identified related applications; Figure 2B is a block diagram illustration of an architecture for a management system for performing transactions using a smart object, according to the related applications; and

Figure 3 is a block diagram illustrating a method for loading data on a smart object representing a transaction using a browser and a read/write interface according to some embodiments of the invention. DETAILED DESCRIPTION OF THE INVENTION

Introductory Overview:

The present invention, in some embodiments, relates to smart object technology, and more particularly, but not exclusively to methods and systems for managing smart objects, including, but not limited to smart cards, smart objects integrated in mobile devices, using Host Card Emulation (HCE) technology or other portable object emulation technology and other portable smart object.

Broadly stated, according to an aspect of some embodiments of the invention, systems and methods are provided, which employ features of the systems and methods disclosed in the above-identified related applications, and are utilized to preorder a variety of transactions such as a one-time or periodic maintenance or other service contract, for example, for public transportation, or another type of transactions such as adding value to a smart object that functions as an electronic wallet and later to facilitate performance of the contract or make payments from the electronic wallet. The preorder and the utilization may take place at the same or different loading station (user interface) locations. According to such embodiments, the invention addresses possible time-consuming delays that may result from multiple individuals attempting to utilize a single (or one of a small number of) loading stations at the same time.

According to some embodiments, and as in the related applications, management of the preordering and utilization are preferably managed by a CMU. Also, as in the related applications, interfaces through which the CMU can be accessed, provide the ability to read from and, preferably also to write to a smart object. Non limiting examples of such interfaces include train station ticketing facilities, turnstiles, bus receipt generating devices, cell phones having Host Card Emulation (HCE) or other portable object emulation technology, computers equipped with a conventional card reader Automatic Teller Machines (ATMs), etc.

A feature of some embodiments of the invention is that the details of the preordered transaction are stored in a database managed by the CMU, preferably in a Cloud service, until the smart object holder requests performance of the ordered transaction. Performing the transaction is automatically carried out by any compatible smart object interface coupled for two-way communication to the CMU, and payment is charged only when the particular transaction is actually activated for the smart object. Optionally, however, payment or partial payment may be charged at the time of the order. According to some embodiments, details concerning the transaction include, but are not necessarily limited to, identification of the provider of the service or goods contracted for, the time at which (or a period of time during which) the service will be provided, details as to the intended source of payment for the transaction, identification of the smart object, relevant information about the smart object holder (e.g., age, status), and the cost of the services. Non-limiting examples of possible transactions include a monthly subscription for public transportation, an ordering for a service contract for another person's smart object, such as the smart phone of a child, cancelling an ordered transaction, and performing a service action in the smart object, e.g. updating discounts entitlement, compensation such as feree rides due to system failures, etc. According to some embodiments, other information such as reorders of previous transactions, even if already fully executed, may also be stored in the database. Optionally, the user may provide a list of several payment sources, which may be updated at the time an order is placed or at any other time. All the stored information accessible by all the interfaces capable of reading and loading the ordering smart object or reading the identifier on the smart object and intercommunicating with the CMU.

When the smart object is later identified and authenticated by the same or a different interface, and the user requests activation or execution of a preordered transaction, the interface initiates a request to the CMU to verify the existence of a request for the transaction in the CMU database and availability of any necessary payment through the designated payment source. If all is in order, the transaction is enabled and the interface automatically performs the transaction.

In some embodiments, this is done by receiving the transaction details from the CMU and loading them in the smart object. At the same time, the CMU debits the pre-designated payment source to obtain payment.

Preferably, however, according to some embodiments, nothing is loaded onto or written into the smart object. Instead, the interface reads a "key" from the smart object, sends it for identification to the CMU. After the CMU verifies the identity the user, the existence of the transaction, availability of funds for payment, it send back a signal to the interface to allow the transaction to proceed, e.g., for user to pass through a turnstile or obtain the desired product or service.

As will be appreciated, that if verification fails, the CMU sends the interface an indication that that transaction was not allowed, which is then displayed to the user. According to some embodiments, where necessary, communication is provided via a proxy server to permit components, which use different communication protocols, to communicate with one another. The CMU is disposed in or accessible through the Cloud and can be accessed from anywhere in the world via the World Wide Web (Internet).

To summarize, according to aspects of some embodiments of the present invention, functions that can be provided include:

• pre-ordering of service contracts for loading on the smart object at a later date, such as a monthly subscription for train or bus fare;

• ordering a service contract for another person's smart object, such as a child, wherein loading the contract is automatically performed at a later time by any smart object reader coupled to a server or the cloud, and where payment is charged only when the particular contract is actually loaded to the smart object by placing the smart object in or next to the reader; • pre-arrangement by a school or organization for transportation for a group of students or participants, each having their own smart object.

• adding value for payment of non-subscription services such as transportation or to allow the smart object to be used as an electronic wallet;

• management of "many to many" sales, i.e., sales by multiple distributors of products of multiple service providers.

Among the features of the invention are extreme security, provided by strong authentication during remote access, through use of physical encryption keys in a server associated with the CMU, using advanced (state of the art) secure mechanisms or in any other suitable and desired manner.

As mentioned above, the system and method are operative on substantially any processing platform (end user interface) having access to the Internet. These platforms can include, but are not limited to, point of sale (POS) stations having suitable embedded operating systems located in stores or in kiosks, ATMs, suitably equipped train station entry turnstiles and bus fare receipt delivery devices, etc.

Additionally, if the smart object owner has access to a personal computer connected to the internet and equipped with any browser, , and having an embedded SDK and a dedicated smart device interface, or a smart phone, a tablet or other hand held device having an embedded SDK with an NFC (Near Field Communication) component, these can service as end-user interfaces, and use of public interfaces for pre-storage of contract, value, or other information can be avoided altogether.

Exemplary Embodiments:

Referring now to Figure 1A, there is shown a flow chart illustrating a method for preordering the automatic performance at a later time or date of a transaction on a conventional smart object according to some embodiments of the present invention. First, a transaction, for example, a contract, for later implementation or the addition of value is requested by a user (block 1 10). The user then inputs identifying details of the smart object by which the transaction is to be performed, details of the transaction, time intervals or other rules for performing the transaction, if any, (for example, loading a new contract when the oldest contract is almost at an end) and payment source details, such as a credit or debit card number (block 112). The identifying details of the smart object provide sufficient information for the smart object to be identified by the interface when the card is read sent to the CMU for identification.

The identifying details may be provided manually using a touch screen or keyboard of the interface or even verbally. Alternatively, this information may be read directly from the smart object by the interface. Details of the transaction can be input, for example, by clicking on, or otherwise selecting, one transaction from a displayed list, again using a touch screen, or a keyboard, or verbally. Optionally, details of recent transactions may be read from a Cloud-stored database and transmitted to the interface for display as a prompt menu to aid the user.

Optionally, the order of the process at 1 10 and 1 12 can be reversed, if desired, as will be understood by those skilled in the art.

According to some embodiments, the system may be operative to permit a single user to order, in advance, different transactions for multiple smart objects of the same or different types owned by the user, or on behalf of different owners during a single session.

After entry of the information at 110 and 1 12, a communication session between the interface and the CMU is initiated. Optionally, this may take place between 1 10 and 1 12. The information entered at 1 10 and 1 12 is then transmitted to the CMU and is reviewed for validity. If all is in order, the transaction is accepted and the details are stored in the Cloud database associated with the CMU (block 1 14) where it is accessible by all interfaces that are compatible with the user's smart object. The confirmation may include manual or verbal confirmation by the user that the information is correct and automatic, verification of other information performed by the CMU. Such other information may include whether the requested transaction is permissible for the user, if the smart object has been reported as lost or stolen, etc.

Optionally, the transmitted information may be reviewed manually at the CMU if it is operated by attendants. Optionally, if payment will be required when the transaction is executed, the pre-stored or user-selected payment source details may be used to reserve or set aside, in any conventional manner, an amount of money that covers the cost of the transaction.

When the user wishes to activate or actually perform the preordered transaction, the smart object is read by any compatible interface connected to the system (block 1 16). The interface then requests approval from the CMU. This may include transmission to the CMU of a key number or a PIN number or may be accomplished in any other conventional manner. The approval request may also ask the CMU server whether a transaction has been authorized for that smart object (block 1 17). Optionally, no specific request for approval is needed; the authorization check is performed automatically after the smart object is authenticated.

According to some embodiments, the CMU server sends a reminder some time before the due date for implementation of the transaction to the smart object's owner that a transaction has been ordered and is waiting to be activated or performed, and instructing the owner to take the object to a compatible interface (block 1 15).

Verification that there is a pre-stored transaction for the smart object is then performed by the CMU server by checking the associated database (block 1 18). If there is no stored transaction, no change will be made to the smart object, i.e., no information will be loaded and a notification to that effect is transmitted to the interface for display to the user (block 120).

If a stored transaction is found, the transaction is performed or loaded automatically on the smart object (block 122). Once performance of the transaction has been confirmed, payment for that portion of the transaction, if any, is debited from the reserved amount or from the account of the one who ordered the transaction, using the payment source details stored in the CMU server database for the user account (block 124). Optionally, the CMU server may then check the database to determine whether there is another transaction that has been ordered for that smart object (block 126). If not, an instruction is sent to the interface to end the session. Optionally, if another pending transaction is found, a reminder of the next transaction may be sent to the smart object owner (block 1 15).

According to alternative embodiments of the invention, for purposes of these transactions, most of the characteristics of the smart object need not be utilized. All that is required for such embodiments of the method and system is a unique identifier of the smart object be transmitted to the CMU server which can then verify that the transaction can proceed, e.g., that funds are available for payment, that the smart object has not been lost or stolen, and that the transaction is performed for the correct object or object holder.

Further, in such embodiments the transaction, for example, a monthly transportation pass, can be enabled or the transaction, e.g., entry through the gate to ride on a train or bus or printing of a theater ticket, can proceed without details of transaction being transferred to the smart object. All that the CMU server needs to send is an authorization signal.

An additional benefit of such embodiments is that the smart object does not need to store many personal details of the holder. This minimizes the adverse consequences of loss or theft of the object since all-important information about the object owner and pending and enabled transactions is held securely in the CMU database.

Figure IB is a flow chart illustrating a method for ordering, in advance, the automatic performance at a later date of transactions in a smart object that merely consists of a unique identifier, according to alternative embodiments of the present invention.

As in Figure 1 A, the method begins with preordering of a transaction according to the steps indicated by block 1 10, 1 12, and 1 14 as described above.

Also, as in Figure 1A, the CMU server may send a reminder to the user as in block

1 15.

The initial steps involved in activating or performing a preordered transaction are also the same as those described above in connection with blocks 1 16-120. If a stored transaction is found, the transaction is performed automatically (block 123). For example, if the transaction is to permit the object holder to ride a train, a signal is sent from the CMU server to the interface to open a gate without any information needing to be stored in the smart object.

Once performance of the transaction has been confirmed, payment for that portion of the transaction is debited, if necessary, again as described above for block 124 and the CMU server consult the database to determine whether there is another transaction that has been ordered for that smart object (block 126). If not, the session is ended.

If there is another pending transaction, a reminder may be sent to the smart object owner as in block 1 15.

Non-limiting examples of transactions that can be performed according to embodiments of the invention include:

• A user orders a transaction for a smart object, includes details of payment means for the transaction, and later implements the transaction in the smart object using any interface connected to the system.

• A user orders a renewable subscription, according to defined rules. These rules can set forth, for example, the timeframe of renewal (monthly, weekly, etc.). At or just before the start of each pre-defined interval, the user takes the object to any conveniently located interface, which automatically activates the transaction for that period and automatically debits the user's selected account for that portion of the transaction. In some embodiments, for a subscription for a monthly contract or a subscription for a multi-pass card, whenever only a pre-selected number of trips remain on the card, additional trips can be added. Optionally, the interface may include the capability of printing a new card for the user.

• The smart object as an electronic wallet. In such an embodiment, when the balance in the wallet falls below a pre-defined amount, a pre-selected amount is charged to the user's account and added to the card. Such a transaction can be initiated by the user at any convenient interface, or the transaction may proceed automatically with the added value recorded in the user's account in the Cloud database.

• The smart object can be used as a travel ticket for an unlimited travel contract having a limited time period when it is operative. This can be ordered, for example, up to a year or more in advance. The user can use this ticket freely, for as many trips as he or she desires during that time. This use is monitored or managed in the CMU server. When indications that the card has been used reach the CMU server, these trips are associated with that user and his unlimited use contract. The server uses the actual use statistics to calculate the price of the unlimited ticket, for example, according to logic in the server. In this case, pre-payment can be made of a selected amount from which the cost of each trip is deducted once details of the various trips are uploaded to the server. Only after the price has been calculated is the actual charge debited to the user's account or credit card. This calculation can be performed monthly, weekly or daily, as desired. As noted above, more than one transaction can be preordered for a particular smart object. When more than one transactions is pending, a list can be presented to the object owner by the interface, or optionally, in an email or a text message, or in any other suitable fashion. The user then can select one or more transactions to be activated or performed at any given time, as he or she may require.

According to some embodiments, a smart device owner may establish a special conditions profile or filter to be stored in the CMU database so anonymous users or users other tha the smart object owner, can order reserved contracts for a specific customer profile. This option may be made available only if a card is not presented to an interface when a transaction is initiated. This ensures that users who present a card do not try to reload contracts to which they are not entitled.

According to some embodiments, each user may access a page on the website on which he or she can find and manage the names and numbers of his smart objects. Report loss or theft, change payment source details and make other changes to the information stored in the CMU database.

A system 130 for performing transactions in a smart object, constructed and operative in accordance with some embodiments of the present invention is illustrated schematically in Figure 1C. System 130 includes at least one, and preferably a plurality of smart objects 132. (Only one smart object 132 is illustrated for ease of viewing.) Smart objects 132 each include at least a unique identifier 133 and may to activate an interface and to initiate the preordering, activation or performance of a transaction.

System 130 further includes at least one CMU server 136 with a processor (not shown) and a database or memory 137. Server 136 can be any appropriate server and preferably is disposed in the Cloud 138 for access via the Internet.

At least one, and preferably a plurality of smart object interfaces with read/write capability 134 are coupled for two-way communication to the server 136. Interfaces 134 may also be coupled to one or more actuatable mechanisms, such as a turnstile. Upon authentication of a smart object 132 by the server 136 and determination that an ordered transaction awaits the smart object in the database 137, the object reader 134 performs the transaction.

When the object is a conventional smart object, the object reader can perform the transaction on the smart object itself. Alternatively, for a conventional smart object or for a smart object that only includes a unique identifier, the interface can operate a separate mechanism such as train station turnstile or a vending machine to permit the smart object owner to realize his or her rights under the transaction.

While the method of the present invention can be implemented by a variety of systems for performing transactions in smart objects, suitable examples of systems and methods for performing the actual transactions on the smart objects are described in detail in Applicant's above-identified related applications. It should be recalled that interfaces usable according to the systems and methods of the invention may be operative on substantially any processing platform having access to the Internet. These platforms can include, but are not limited to, an enabled smart cellular phone having an embedded SDK and a Near Field Communication (NFC) component, point of sale (POS) stations having an embedded operating system, a kiosk, ATM, a personal computer or tablet with any browser, and an embedded SDK as well as dedicated smart object read/write devices.

Referring now to Figure 2A, there is shown a schematic illustration of an exemplary system 1 and method suitable for implementation of the present invention. This system isdescribed in the above-identified related applications, but it is to be understood that, alternatively, other systems for ordering and storing transactions in the Cloud can be utilized.

System 1 includes a CMU 6, preferably disposed in the Cloud, multiple interface stations such as 5 and secure access modules ("SAMs") 8 corresponding to each of the smart object operating standards supported by the system. CMU 6 performs the functions needed to process requested transactions including validating and executing service requests from the users of the smart objects, controlling the interfaces, providing secure communication, etc., as will be understood by those skilled in the art.

The communication interface functions of the CMU manages intercommunication with the smart objects through the smart object interface units 5 by way of its own embedded SDK. For example, three smart objects 2 are indicated in Figure 2A each operating under a different standard, for example EMV (standard A), MIFARE (standard B), and QR (standard C), all of which are conventional and well known to those skilled in the art. An SDK 4 is provided under a hosted application in each smart object read/write interface 5. The SDKs are compatible with all the supported smart objects. CMU 6 is also in communication with a plurality of secure access modules 8, each of which is based on a different smart object operating standard. In this way, the central management system can receive a suitable key for each interface according to the standard of the smart object using an interface at a given time. As described above, a transaction begins when a smart object is introduced into or placed in proximity to a compatible interface unit 5. The embedded SDK 4 in the interface unit transmits an initiation request to CMU 6. The CMU identifies the standard or communication protocol of the smart object accessing the interface and requests an encryption key from SAM 8 corresponding to the identified standard of the object. The SAM 8, in turn, authenticates the object 2 preferably by means of a physical key, for example, using a public key and a private key. Once the object has been authenticated, the CMU opens a communication channel between its own SDK and that of the interface and instructs the interface SDK which communication protocol should be used when performing operations on that smart object. The CMU 6 manages the various transactions and operations by sending of instructions to the interface SDK including what to ask or instruct the smart object at each stage.

In this way, a single CMU can control the authentication and operation of a plurality of smart objects running any one of multiple standards and over any one of multiple platforms. It will be appreciated that this system arrangement permits these operations to be conducted simultaneously on a plurality of smart objects. Use of secure access for communications enables communication through the cloud with a strong security mechanism.

With reference to Figure 2B, there is shown a block diagram illustration of an exemplary architecture 10 of a system for performing operations on a smart object, according to some embodiments of the invention. Architecture 10 includes remote loading service by way of CMU 12, typically disposed in the Cloud. CMU 12 communicates with, and operates over, a provider's backend 14, and over a communication channel 24, a provider's client 16, and an encryption unit 26.

CMU 12 includes a remote loading backend 50 coupled to a transaction database 52 wherein details of each transaction are stored. Backend 50 is also coupled to a queue 54 of transactions to be handled. Queue 54 is also coupled to a movements server 56 that sends it log reports. A movements database 58 is coupled to the movements server. In the illustrated embodiment, CMU 12 includes all the components necessary to manage the various services remotely, except for creating a connection between the browser and the host, which is performed by encrypted communication unit 18. Communication unit 18 includes a plurality of secure encryption units 26 shown as part of the SAM server, and a web services managing server 28, here illustrated by way of example only, as a Tornado server, a generally available open source system. Tornado server 28 implements the transaction process and is responsible for managing and creating the secure communication connection between the encryption component (SAM) 26 and the SDK 20 that is embedded in the end user host device 5 (see Fig. 2a).. Tornado server 28 is also coupled to queue 54 and sends reports regarding transactions to the remote loading backend 50 for storage in the transaction database 52. Preferably, CMU 12 is coupled remotely to the SAM server 26 for transferring movements data, when required.

The Provider's Backend 14 is a backend server of a service provider or store that sells the services available to the smart object owners. Backend server 14 is coupled to a store database 32 from which information as to ordered transactions are loaded on the purchasers' respective smart objects. Records of the transactions of each service provider purchased by end users are stored in its store database 32. Communication with CMU 12 is accomplished by means of a communication channel 24 using representational state transfer (REST), a conventional architectural style commonly used for developing web services as will be well known to those skilled in the art.

Communication channel 24 includes a data model server 25 and may include a proxy server (not shown). The Provider's Client 16 is the end user (smart object read/write interface) of each service provider. There are two main groups of end users - those designated 15, such as smart phones, having NFC capabilities or native communication with smart objects that can communicate directly over the Internet, and those designated 17, such as personal computers with attached smart object read/write units 17', that cannot communicate directly over the Internet, typically due to security issues. In the case of devices that can communicate over the Internet, a "dumb" SDK 20 is embedded in the device 15 and can communicate with the CMU 12 over a secure Web socket 27 created by the Tornado server 28. As described in the related applications, communication is provided by four main components: an SDK 20 embedded in a host user interface (provider's client), a communication channel 24, a SAM server 26 and a web services managing server 28. It will be appreciated that the SDK is a generic SDK. In other words, the SDK for each end user interface includes the same code, only having a different communication protocol or channel, according to the host.

A method for loading data on a smart object representing a transaction using a browser and a card read/write interface, according to some embodiments of the invention, is illustrated schematically in Figure 3, by way of non-limiting example, only. The method is as follows: 1) The SDK software component 72 is installed on the host computer 70. 2) The user initiates a transaction 60, e.g., chooses a transaction for loading to the card or requests adding value to the card, and inputs his payment source details, either manually by means of a touchscreen or keyboard, or even verbally, or the interface reads the information directly from the smart object if that information is not already in the CMU database. 3) The backend server of the service provider requests (at 62) a transaction from the

CMU and requests authentication. The CMU authenticates (at 64) the service provider and validates the request. It will then generate a unique token or key 66 using the SAM service or other authentication server. The token indicating grant of permission for the requested transaction is transferred (at 68) to the provider backend, which then provides the token 69 to the SDK 72 of the end user (host).4) The end user device displays a link on the display screen with the relevant uniform resource indicator (URI) schema to conduct the transaction. After the user clicks on the link, a web browser page will be displayed to the user asking whether to run the application associated with that URI. 5) The choice of "Launch Application" will activate the Embedded HTTP Server component or the SDK 72, which will check for available contracts or updates with the SAM server of the service provider and, if any exist, will download them (at 76) to the CMU which will indicate to the end user which updates are available. 6) The SDK component will activate the HTTP server: for the website and listen on the pre-selected port. 7) No indication need be provided to the user during this process. 8) In parallel, or after clicking on another link, the browser will connect via the relevant port. 9) If the connection is successful, the interface of the host computer can now communicate with the central management unit via the browser. 10) After determining that both sides are connected, the token for performing the transaction will be transferred from the HTTP server to the component in the SDK to perform the transaction. If the card is not connected, an indication 74 is provided, as by means of an error message from a component in the SDK, which is transferred to the browser in the host for display to the user. If the card reader is not connected, an indication must be provided in the same fashion. If all connections are in place, the central management unit will send instructions to load 78 the contract to the card. 1 1) When loading to the card is complete, the SDK component will provide a suitable message to the HTTP component and to the central management unit. 14) The HTTP component will return a suitable message to the browser to be displayed to the user. 12) The CMU will send (at 79) a success or error message to the provider backend to update its database.

General Comments:

Section headings herein are intended only as informative, and are not to be construed as limiting in any way. Nor are the cited related applications to be considered as admitted prior art.

Implementation of the method and/or system of embodiments of the invention can involve performing or completing selected tasks manually, automatically, or a combination thereof. Moreover, according to actual instrumentation and equipment of embodiments of the method and/or system of the invention, several selected tasks could be implemented by hardware, by software or by firmware or by a combination thereof using an operating system.

For example, hardware for performing selected tasks according to embodiments of the invention could be implemented as a chip or a circuit. As software, selected tasks according to embodiments of the invention could be implemented as a plurality of software instructions being executed by a computer using any suitable operating system. In an exemplary embodiment of the invention, one or more tasks according to exemplary embodiments of method and/or system as described herein are performed by a data processor, such as a computing platform for executing a plurality of instructions. Optionally, the data processor includes a volatile memory for storing instructions and/or data and/or a non- volatile storage, for example, a magnetic hard-disk and/or removable media, for storing instructions and/or data. Optionally, a network connection is provided as well. A display and/or a user input device such as a keyboard or mouse are optionally provided as well.

While the invention has been described with respect to a limited number of embodiments, it will be appreciated that many variations, modifications and other applications of the invention may be made. It will further be appreciated that the invention is not limited to what has been described hereinabove merely by way of example. Rather, the invention is limited solely by the claims which follow.