Patent Description:
Conventionally, individuals and businesses may ship items to a recipient using a container, such as a box or envelope. While some of these containers may provide tamper-evident seals, these tamper-evident seals may only indicate that the container may have been opened during a shipping process (e.g., after leaving a sender's location and arriving at a recipient's location). These tamper-evident seals do not secure the container from actually being opened by anyone other than the intended recipient.

<CIT> discloses a method of monitoring the transport of goods in which the geographical location of a container and date are tracked and an unlocking code for the container is activated by a control centre if the geographical location and date agree with a predetermined location and date. <CIT> discloses a method and system for setting entry codes via a communications network for access to moveable enclosures, while <CIT> discloses systems and methods for accessing or managing secured storage space.

The present invention provides a computer implemented method, a system and a machine readable medium as defined in the appended claims.

Various ones of the appended drawings merely illustrate example embodiments of the present invention and cannot be considered as limiting its scope.

The description that follows includes systems, methods, techniques, instruction sequences, and computing machine program products that embody illustrative embodiments of the present invention. In the following description, for purposes of explanation, numerous specific details are set forth in order to provide an understanding of various embodiments of the inventive subject matter. It will be evident, however, to those skilled in the art that embodiments of the inventive subject matter may be practiced without these specific details. In general, well-known instruction instances, protocols, structures, and techniques have not been shown in detail.

Example embodiments described herein provide systems and methods for an authenticated coded locked container. In example embodiments, a digitally encoded lock mechanism that is used to lock a container is determined. For example, the digitally encoded lock mechanism may be a code or image that is used to lock or unlock the container. An access key provided by a recipient or a device of the recipient is received. The access key may be provided over a communication network to the recipient or the device of the recipient of the container such that the recipient can use the access key to unlock the container. An authentication process is performed that determines whether the access key triggers the unlocking of the container (e.g., whether the access key matches the digital encoded locking mechanism). According to the invention, the determination process is performed at the container, according to non claimed embodiments, the determination process may be performed at at a central server of a security provider system, or at the device of the recipient. In some non claimed embodiments, the central server relays the access key to the recipient or the device of the recipient. During the relay process, the central server may store a copy of the digitally encoded lock mechanism that may be used to match against the access key. Based on the access key matching the digitally encoded lock mechanism, instructions to automatically unlock the container are provided. By using example embodiments of the present invention, containers may be secured during a shipping process.

With reference to <FIG>, a diagram illustrating an example environment <NUM> in which embodiments of a system for providing a handshake authenticated locked container is shown. The environment <NUM> may comprise a container <NUM>, a central server <NUM> of a security provider system, a sender device <NUM>, and a recipient device <NUM>. The container <NUM> may comprise a box, an envelope, a shipping container, or any other housing capable of holding content to be shipped from a sender <NUM> to a recipient <NUM>. In alternative embodiments, the container <NUM> may be a vehicle or a residential structure (e.g., house, apartment). The container <NUM> will be discussed in more detail in connection with <FIG>.

The central server <NUM> manages access to the locked container <NUM>. In some embodiments, the central server <NUM> receives a digitally encoded lock mechanism (e.g., a code or instructions) that is use to lock the container. In some embodiments, the digitally encoded lock mechanism may be, or may indicate, the access key to unlock the container <NUM>. The digitally encoded lock mechanism may be stored at the central server <NUM> and a corresponding access key may be relayed by the central server <NUM> to the recipient <NUM> (e.g., to the recipient device <NUM>). While only one central server <NUM> is shown, alternative embodiments may comprise any number of central servers <NUM> to perform operations of the security provider system. The central server <NUM> will be discussed in more detail in connection with <FIG>.

The sender device <NUM> may, in some embodiments, be used by the sender <NUM> to send the access key to the recipient <NUM>. The sender <NUM> may be a human user (e.g., a human being), a machine user (e.g., a computer configured by a software program to interact with the sender device <NUM>), or any suitable combination thereof (e.g., a human assisted by a machine or a machine supervised by a human). The sender <NUM> is not part of the environment <NUM>, but is associated with the sender device <NUM> and may be a user of the sender device <NUM>. For example, the sender device <NUM> may be a smartphone, a telephone, a desktop computer, a vehicle computer, a tablet computer, a portable media device, a smartphone, a wearable device (e.g., a smart watch or smart glasses), or any other device capable of making a call or transmitting or otherwise communicating a message.

In example embodiments, the access key may be sent directly to the recipient <NUM> or be relayed through the central server <NUM> to the recipient <NUM>. For example, the sender <NUM> may manually enter the digitally encoded lock mechanism into an input unit on the container <NUM> to lock the container <NUM>. The sender <NUM> then sends (e.g., calls, e-mails, or texts) a copy of the entered digitally encoded lock mechanism (e.g., which may form the access key) to the recipient <NUM>, the recipient device <NUM>, or the central server <NUM>. In alternative embodiments, the container <NUM>, itself, may send the copy of the entered digitally encoded lock mechanism (e.g., the access key) to the recipient <NUM>, the recipient device <NUM>, or the central server <NUM>.

The recipient device <NUM> comprises any device of the recipient <NUM> that can receive a copy of the digitally encoded lock mechanism (that may be used as the access key) or another form of the access key (e.g., a thumbprint or a voice signal) to unlock the container <NUM>. For example, the recipient device <NUM> may be a landline telephone on which the recipient <NUM> receives an audio call (e.g., from the sender <NUM> or the central server <NUM>) indicating the access key. Alternatively, the recipient device <NUM> may receive a series of dual-tone multi-frequency (DTMF) tones as the access key. In other examples, the recipient device <NUM> may be a mobile device having an application installed thereon capable of receiving the access key and determining whether to send instructions to the container <NUM> to unlock the container <NUM>. The recipient device <NUM> will be discussed in more detail in connection with <FIG>.

The recipient <NUM> may be a human user (e.g., a human being), a machine user (e.g., a computer configured by a software program to interact with the recipient device <NUM>), or any suitable combination thereof (e.g., a human assisted by a machine or a machine supervised by a human). The recipient <NUM> is not part of the environment <NUM>, but is associated with the recipient device <NUM> and may be a user of the recipient device <NUM>. For example, the recipient device <NUM> may be a smartphone, a telephone, a desktop computer, a vehicle computer, a tablet computer, a portable media device, a smartphone, a wearable device (e.g., a smart watch or smart glasses), or any other device capable of making a call or transmitting or otherwise communicating a message.

The copy of the digitally encoded lock mechanism or the access key may be sent using any communication network. Accordingly, the communication network may be a wired network, a wireless network (e.g., a mobile or cellular network), or any suitable combination thereof. The network may include one or more portions that constitute a private network, a public network (e.g., the Internet), or any suitable combination thereof. Accordingly, the network may include one or more portions that incorporate a local area network (LAN), a wide area network (WAN), the Internet, a mobile telephone network (e.g., a cellular network), a wired telephone network (e.g., a plain old telephone system (POTS) network), a wireless data network (e.g., WiFi network or WiMAX network), or any suitable combination thereof. Any one or more portions of the network may communicate information via a transmission medium. As used herein, "transmission medium" refers to any intangible (e.g., transitory) medium that is capable of communicating (e.g., transmitting) instructions for execution by a machine (e.g., by one or more processors of such a machine), and includes digital or analog communication signals or other intangible media to facilitate communication of such software.

<FIG> is a block diagram illustrating an example embodiment of the container <NUM>. The container <NUM> comprises a housing (not shown explicitly) capable of holding and securing content to be shipped to the recipient <NUM>. Additionally, the container <NUM> includes a locking device (not shown explicitly) that may be locked by the sender <NUM> after the sender <NUM> places content within the container <NUM>. The locking device may comprise or be linked to a code module <NUM>, a Bluetooth® module <NUM>, a location module <NUM>, an authentication module <NUM>, or a lockdown module <NUM>. The container <NUM> may also comprise one or more security components <NUM>. Each of the modules and components may be communicatively coupled together.

The code module <NUM> manages the receipt of codes to lock and unlock the container <NUM>. In some embodiments, the code module <NUM> may include or be coupled to a (physical or virtual) keyboard or keypad that receives an entered digitally encoded lock mechanism from the sender <NUM> to lock the container <NUM> and receives an entered access key or code from the recipient <NUM> to unlock the container <NUM>. In other embodiments, the code module <NUM> may include or be coupled to a microphone that receives an audio access key or code. For example, the audio access key may comprise a series of one or more DTMF tones. Further still the audio access key may be a voice of the recipient <NUM> in embodiments having a voice recognition code module (not shown).

The Bluetooth module <NUM> manages communications with various devices via Bluetooth, such as for the receipt of the access key via Bluetooth from the recipient device <NUM>. In some embodiments, the access key is a code that is entered into or received from the recipient device <NUM>. For example, the recipient <NUM> may enter the access key into an unlock application operating on the recipient device <NUM>, and the recipient device <NUM> may transmit the access key to the Bluetooth module <NUM>. In other embodiments, the access key comprises instructions from the recipient device <NUM> to unlock the container <NUM>. For example, the instructions may be received in response to a thumbprint application operating on the recipient device <NUM> verifying a (previously stored) thumbprint of the recipient <NUM>. In example embodiments, Bluetooth capabilities may be powered by a battery, kinetics, or solar power (e.g., panels on the container <NUM>).

The location module <NUM> manages access to the content locked in the container <NUM> based on a location of the container <NUM>. Accordingly, the location module <NUM> may comprise or be coupled to a global positioning system (GPS). In one embodiment, when the location module <NUM> detects arrival at a location associated with the recipient <NUM>, the location module <NUM> may instruct the container <NUM> to unlock (e.g., provide an access key that is an instruction to unlock the container <NUM> to the authentication module <NUM>). In other embodiments, the location module <NUM> may provide, for example, a second or third factor for the authentication process. For example, the container <NUM> may only open if both the code (e.g., access key) entered by the recipient <NUM> matches the digitally encoded lock mechanism and the container <NUM> is in the location corresponding to the recipient <NUM> (e.g., a shipping address of the recipient <NUM>). In another embodiment, the container <NUM> may only open if the code (e.g., access key) entered by the recipient <NUM> matches the digitally encoded lock mechanism, a signal is received from the recipient device <NUM> verifying a thumbprint of the recipient <NUM> (e.g., using a thumbprint application operating on the recipient device <NUM>), and the container <NUM> is in the location corresponding to the recipient <NUM> as determined by the location module <NUM>.

The location module <NUM> may also provide alerts based on location. For example, a courier may have a plurality of containers for delivery (e.g., in their truck or in a drone). Each container may have, for example, a red/green LED light that will indicate (e.g., turns green) when at a proper location (e.g., location of the recipient <NUM>). Alternatively, an audio signal may be given when at the proper location. In these embodiments, an address label may be optional. Additionally, the location module <NUM> may provide a signal (e.g., blinking red LED light or audio signal), when the container <NUM> has traveled off course (e.g., by a predetermined amount) from a location of the recipient <NUM>. Further still, the courier may, in some embodiments, ping each of a plurality of the containers <NUM> to determine which one to deliver at a particular location.

The authentication module <NUM> manages the authentication process at the container <NUM> to determine whether to unlock the container <NUM>. In example embodiments, the authentication module <NUM> may receive the access key in a form of a code and compare the access key to the digitally encoded lock mechanism that was used to lock the container <NUM>. Alternatively, the authentication module <NUM> may receive an audio signal (e.g., DTMF tones or voice of the recipient <NUM>) as the access key and use the audio signal to determine whether to unlock the container <NUM> (e.g., voice authenticated as that of the recipient). Additionally or alternatively, the authentication module <NUM> may receive instructions (e.g., also referred to as an "access key") from the recipient device <NUM> that instructs the authentication module <NUM> to unlock the container <NUM>.

The lockdown module <NUM> manages a lock down process such that the lock on the container <NUM> is disabled from being unlocked until reset. For example, the lockdown module <NUM> may lock down the container <NUM> in response to an entered access key not matching the digitally encoded lock mechanism after a predetermined number of tries. In another example, the lockdown module <NUM> may lock down the container <NUM> based on a determination by the location module <NUM> that the container <NUM> is not in a location corresponding to the recipient <NUM>. Once locked down, the container <NUM> may require a reset to be performed by an authorized agent (e.g., an agent of the security provider system) before attempts to unlock the container <NUM> may be made again. For example, the recipient <NUM> may need to call or bring the container <NUM> to an agent and provide proof of his or her identity before the container <NUM> is reset.

The security components <NUM> may comprise various sensors and devices that may verify content, verify the recipient <NUM>, or verify proper handling of the container <NUM>. One example of the security component <NUM> may be a camera. The camera may be used to capture an image of the recipient <NUM> and provide the captured image to the authentication module <NUM> in embodiments having a facial recognition authentication process. The authentication of the image of the recipient <NUM> may then trigger the unlocking of the container <NUM>.

Another example security component <NUM> may be a weight scale. The weight scale may measure a weight of the content when initially placed into the container <NUM>. Upon receipt and opening of the container <NUM> by the recipient <NUM>, the weight of the content may be verified by the weight scale. Thus, if content is missing, the weight upon receipt will not match the weight upon initial placement into the container <NUM>.

Yet other security components <NUM> may be an accelerometer or gyroscope. The accelerometer may indicate if the container <NUM> was thrown or experienced a sudden stop in movement. The gyroscope may indicate if the container <NUM> was shipped in a proper orientation. The use of the accelerometer or the gyroscope may be useful in embodiments where fragile content is shipped.

A further security component <NUM> may be a bill counter. The bill counter may be employed in a container <NUM> that is used, for example, to deposit cash to a bank, make a cash withdrawal, or to make a cash payment. The bill counter may scan the cash as it is placed into the container <NUM>. In one embodiment, the recipient <NUM> may be able to confirm the amount of cash in the container <NUM> without having to open the container <NUM> based on data from the bill counter. In one embodiment, the container <NUM> may display information regarding the amount of cash to the recipient device <NUM>.

Another security component <NUM> may be a visual display. The visual display provides validation that correct content is being placed into the container <NUM>. For example, a pharmacist or other person that is actually putting the content in the container <NUM> can see a picture of what they are supposed to place in that container <NUM> on the visual display. Additionally, the recipient <NUM> can also see and verify what content should have been placed in the container <NUM> when the recipient <NUM> opens the container <NUM>.

Additionally, the container <NUM> may be tamper-resistant. For example, a security component <NUM> may be an oxygen (O<NUM>) bottle that explodes if the container <NUM> is not properly unlocked and opened. In another example, the security component <NUM> may be a form of liquid that may destroy documents in the container <NUM> if the container <NUM> is not property unlocked and opened. Furthermore, the container <NUM> may be waterproof (e.g., has a gas pressure valve so as not to pop open when depressurized).

In some embodiments, the container <NUM> may also have or be coupled to a cooling system. For example, the content may be perishable (e.g., food, organ donations, or cold storage drugs such as vaccines that need to be in a certain temperature range). In one embodiment, the container <NUM> may plug into an external cooling system that provides external refrigerant or cooling. In this embodiment, the container <NUM> may dock into a delivery vehicle and pulls power from the delivery vehicle. The cooling system ensures that a temperature is maintained within a specified temperature range. Additionally, if the internal temperature varies from the specified range, the recipient <NUM> may be alerted (e.g., via a display with an alert pushed to the recipient device <NUM>), so that they can reject the shipment.

<FIG> is a block diagram illustrating an example non claimed embodiment of the central server <NUM> of the security provider system. The central server <NUM> manages access to the locked container <NUM> in some embodiments where the container <NUM> does not perform the authentication or where the access key is not directly sent from the sender <NUM> to the recipient <NUM> (e.g., relayed through the central server <NUM>). Accordingly, the central server <NUM> may comprise at least certain components including a code module <NUM>, a relay module <NUM>, a location module <NUM>, an authentication module <NUM>, a register module <NUM>, and a data storage <NUM>.

In example embodiments, the code module <NUM> manages the receipt and storage of codes (e.g., a copy of the digitally encoded lock mechanism used to secure the container <NUM>). For example, when the sender <NUM> locks the container <NUM> using the digitally encoded lock mechanism, the central server <NUM> receives an indication of the digitally encoded lock mechanism that is used to lock the container <NUM>. The copy of the digitally encoded lock mechanism may be stored in the data storage <NUM>.

In example embodiments, the relay module <NUM> provides a copy of the digitally encoded lock mechanism (e.g., the access key) to unlock the container <NUM> to the recipient <NUM>. In some cases, the access key is a copy of the digitally encoded lock mechanism. For example, if the sender <NUM> locks the container <NUM> using a numeric code (e.g., "<NUM>"), the access key may be a copy of the numeric code (e.g., "<NUM>"). Thus, the relay module <NUM> relays the access key (e.g., "<NUM>") to the recipient <NUM> or to the recipient device <NUM>. It is noted that in some embodiments, the access key may be sent from the sender <NUM> directly to the recipient <NUM> or the recipient device <NUM>. In these embodiments, the operations of the relay module <NUM> are not necessary. Further still, the access key may be a password or alphanumeric code.

The location module <NUM> may monitor the location of the container <NUM> and trigger location-based operations. In some embodiments, the location module <NUM> may receive location information (e.g., GPS tracking information) of the container <NUM>. In one embodiment, when the location module <NUM> detects that the container <NUM> has arrived at a location associated with the recipient <NUM>, the location module <NUM> may trigger the relay module <NUM> to provide the access key to the recipient <NUM> or the recipient device <NUM>. For example, the location module <NUM> may trigger the relay module <NUM> to call or otherwise communicate with the recipient device <NUM> and provide DTMF tones that will cause the container <NUM> to unlock. In other embodiments, when the location module <NUM> detects the container <NUM> has arrived at a location associated with the recipient <NUM>, the location module <NUM> may trigger the authentication module <NUM> to send instructions to unlock the container <NUM>.

The authentication module <NUM> manages the authentication process at the central server <NUM> to determine whether to unlock the container <NUM>. In some embodiments, the authentication module <NUM> may receive the access key via the container <NUM> from the recipient device <NUM>. The access key may then be compared with the copy of the digitally encoded lock mechanism stored in the data storage <NUM> for that container <NUM>. If the access key is authenticated (e.g., matches the digitally encoded lock mechanism), the authentication module <NUM> may send a signal or instructions to the container <NUM> that causes the container <NUM> to unlock.

The register module <NUM> allows users (e.g., the sender <NUM> or the recipient <NUM>) to register themselves or their user devices with the security service provider. By registering, the user may provide the security service provider with one or more locations associated with the user (e.g., home address, work address, or dedicated shipping address). The locations may then be used by the location module <NUM>. Additionally, the user may provide the security service provider with a list of one or more sender devices <NUM> or one or more recipient devices <NUM> (e.g., provide a MAC address or Bluetooth profile). As a result, the access code may be transmitted by the central server <NUM> to, for example, any of the one or more recipient devices <NUM>. Further still, the registered user may provide biometric information such as fingerprints, a facial image, or voice recording, which may be used to verify an identity of the user (e.g., the recipient <NUM>).

<FIG> is a block diagram illustrating an example embodiment of the recipient device <NUM>. The recipient device <NUM> is a device of the recipient <NUM> that is capable of receiving the access key as well as performing at least some forms of authentication. To enable these operations, the recipient device <NUM> may comprise at least certain components including a code module <NUM>, a thumbprint module <NUM>, a Bluetooth module <NUM>, an authentication module <NUM>, and a data storage <NUM>. The recipient device <NUM> may comprise other components that are not pertinent to example embodiments.

The code module <NUM> manages the receipt of the access key. In some cases, the access key may be received from the sender <NUM> or the sender device <NUM>. In other embodiments, the access key may be received via the central server <NUM>. The access key may be received in any form such as, for example, as a text, in an e-mail, or via a phone call. In some cases, the access key may be stored to the data storage <NUM> for later use. In other cases, the access key may be received upon the delivery of the container <NUM> and may be used directly to cause the unlocking of the container <NUM>. Additionally, the code module <NUM> may receive the access key from the recipient <NUM> that is attempting to unlock the container <NUM>, and provide the access key to the authentication module <NUM>.

The thumbprint module <NUM> manages the authentication of a thumbprint or other print (e.g., palm print or fingerprint) of the recipient <NUM>. Accordingly the thumbprint module <NUM> may comprise or be coupled to a thumbprint scanner that can scan a thumbprint. The thumbprint module <NUM> may then verify that the thumbprint is that of the recipient <NUM> by comparing the thumbprint to one that is stored in the data storage <NUM>. While a thumbprint is discussed, it is noted that any fingerprint may also be used to verify the identity of the recipient <NUM>.

Based on the authentication, the thumbprint module <NUM> may send a signal to the container <NUM> indicating the authentication has been completed. The signal may comprise instructions to unlock the container <NUM>. In one embodiment, the signal is sent by the Bluetooth module <NUM>. The Bluetooth module <NUM> may, in other cases, provide the access key to the container <NUM>. Further still, the Bluetooth module <NUM> may provide the signal to unlock the container <NUM> when the container <NUM> is located within a predetermined distance of the recipient device <NUM> (e.g., based on the recipient device <NUM> detecting a presence of the container <NUM>).

While the thumbprint application and thumbprint module <NUM> were discussed as being a part of the recipient device <NUM>, alternatively, these components may be embodied in, or coupled to, the container <NUM>. As such, the container <NUM>, itself, may comprise a scanner to scan the recipient's thumbprint and verify the recipient's identity. Further still, while example embodiments discuss verifying thumbprints, alternative embodiments may verify any biometrics (e.g., one or more fingerprints, facial recognition, or retinal scan) or voice of the recipient <NUM>.

The authentication module <NUM> provides functionalities similar to the authentication module <NUM> of the container <NUM> and the authentication module <NUM> on the central server <NUM>. As such, the authentication module <NUM> may authenticate the access key and cause a signal to be provided to the container <NUM> to unlock the container <NUM> based on an outcome of the authentication process.

<FIG> is a communication flow diagram for providing access to the container <NUM> that has been locked, according to one example embodiment. The sender <NUM> places content into the container <NUM> and locks the container <NUM>, for example, using a digitally encoded lock mechanism. The sender <NUM> then provides a copy of the digitally encoded lock mechanism (e.g., the access key) to the recipient <NUM>. Accordingly, the access key may be provided directly to the recipient <NUM> (or the recipient device <NUM>) or be relayed through the central server <NUM> to the recipient <NUM> (or the recipient device <NUM>). The access key may be provided in a text, in an e-mail, verbally using a phone call, or using any other means of communication or signaling.

Once the container <NUM> is received by the recipient <NUM>, the recipient <NUM> may provide the access key to the container <NUM> (e.g., to enter into a keypad of the container <NUM>). The container <NUM> may perform an authentication process to determine whether to unlock the container <NUM> (e.g., compare the access key with the digitally encoded lock mechanism to determine if they match). Alternatively, the container <NUM> may provide the access key to the central server <NUM> that performs the authentication process. Based on a determination to unlock the container <NUM>, the container <NUM> is unlocked.

<FIG> is a communication flow diagram for providing access to the locked container <NUM> according to another embodiment. The sender <NUM> places content into the container <NUM> and locks the container <NUM>, using a digitally encoded lock mechanism. In an example, the container <NUM> then provides a copy of the digitally encoded lock mechanism (e.g., the access key) to the sender device <NUM>, the recipient <NUM> (or recipient device <NUM>), or the central server <NUM>, which relays the access key to the recipient <NUM> (or recipient device <NUM>). In one embodiment, the access key is provided by the container <NUM> via Bluetooth. For example, the container <NUM> may send the access key to the sender device <NUM> while the container <NUM> is in proximity to the sender device <NUM>. According to the invention, the container <NUM> sends the access key to the recipient device <NUM> upon delivery to the recipient <NUM> and within range of the recipient device <NUM>.

Once the container <NUM> is received by the recipient <NUM>, the recipient <NUM> provides may provide the access key to the container <NUM> (e.g., enter into a keypad of the container <NUM>). The container <NUM> performs an authentication process to determine whether to unlock the container <NUM> (e.g., compare the access key with the digitally encoded lock mechanism to determine if they match). Alternatively, according to a non claimed embodiment the container <NUM> may provide the access key to the central server <NUM>, which performs the authentication process. Based on a determination to unlock, the container <NUM> is unlocked.

<FIG> is a communication flow diagram for providing access to the container <NUM> after it has been locked, according to a further example embodiment. In this embodiment, the access key is a scannable code. Accordingly, the sender <NUM> places content into the container <NUM> and locks the container <NUM>. In one embodiment, the container <NUM> (or a device of the sender <NUM>) sends the access key in the form of a scannable code (e.g., a QR code) to the recipient device <NUM>. For example, the container <NUM> may, upon being within range of the recipient device <NUM>, provide the scannable code via Bluetooth. Alternatively, the access code may be relayed through the central server <NUM> to the recipient device <NUM>. The access code is displayable on a screen of the recipient device <NUM>.

Upon receipt of the container <NUM> by the recipient <NUM>, the container <NUM> scans the access key from the recipient device <NUM>. In one example, the container <NUM> may comprise a camera or image scanning component to scan the access key displayed on the screen of the recipient device <NUM>. The container <NUM> may then perform an authentication process to verify the scanned access key. Based on authentication of the scanned access key, the container <NUM> is then unlocked. In an alternative embodiment, the container <NUM> may provide the scanned access key to the central server <NUM>, which performs the authentication process.

<FIG> is a communication flow diagram for providing access to the locked container <NUM> according to another example embodiment. The embodiment of <FIG> uses a location of the container <NUM> as a trigger to send the access key to the recipient <NUM>. Accordingly, the sender <NUM> places content into the container <NUM> and locks the container <NUM>. The sender <NUM> (or the sender device <NUM>) then sends the access key to the central server <NUM>. The central server <NUM> may store the access key.

The container <NUM> is shipped and received by the recipient <NUM>. When the container <NUM> arrives at a predetermined location corresponding to the recipient <NUM>, the central server <NUM> sends the access key to the recipient <NUM> (or to the recipient device <NUM>). In one embodiment, the container <NUM> may provide a location signal in the form of position data (e.g., GPS coordinates) to the central server <NUM>. The central server <NUM> may then determine whether the position data corresponds to the location of the recipient <NUM>. In an alternative embodiment, the container <NUM> may have location information (e.g., coordinates) for the predetermined location of the recipient <NUM>. When the container <NUM> detects that it is at the location of the recipient <NUM>, the container <NUM> may send a location signal to the central server <NUM> that confirms arrival of the container <NUM> at the location. Based on the container <NUM> being at the location of the recipient <NUM>, the central server <NUM> sends the access key to the recipient <NUM> (or to the recipient device <NUM>).

The recipient <NUM> receives the access key and may provide the access key to the container <NUM> (e.g., enter the access key into a keypad of the container <NUM>). The container <NUM> may perform an authentication process to determine whether to unlock the container <NUM>. Alternatively, the container <NUM> may provide the access key to the central server <NUM>, which performs the authentication process. Based on a determination to unlock, the container <NUM> is unlocked.

<FIG> is a communication flow diagram for providing access to the locked container <NUM> according to a further example embodiment. The embodiment of <FIG> uses an authentication application on the recipient device <NUM> to perform an authentication process. Accordingly, the sender <NUM> places content into the container <NUM> and locks the container <NUM>. The sender <NUM> (or the sender device <NUM>) then sends the access key to the central server <NUM>. The central server <NUM> may store the access key. The container <NUM> is then shipped to the recipient <NUM>. Once received, the recipient <NUM> may activate the authentication application on the recipient device <NUM>. For example, the recipient <NUM> may activate a thumbprint application. Once the authentication application authenticates the recipient <NUM>, the recipient device <NUM> sends a signal (e.g., access key or instructions to unlock) to the container <NUM> that causes the container <NUM> to unlock.

While various embodiments for opening the locked container <NUM> have been described in <FIG>, further embodiments may combine any two or more of these embodiments or variations of these embodiments to enable a multi-factor authentication process. For instance, the container <NUM> may be unlocked based on the access key matching the digitally encoded lock mechanism and the container <NUM> being in a location corresponding to the recipient <NUM> (e.g., receiving a Bluetooth signal from the recipient device <NUM>). In other example, a three-factor authentication may require that the access key match the digitally encoded lock mechanism, the container <NUM> is at a location corresponding to the recipient <NUM>, and a thumbprint application verifies the recipient's identity.

<FIG> is a flow diagram of a method <NUM> for providing access to a locked container (e.g., the container <NUM>). The operations of the method <NUM> are performed from the perspective of the container <NUM>. In operation <NUM>, content is received (e.g., placed into the container <NUM>). In some embodiments, the content may be verified (not shown explicitly) as it is placed into the container <NUM>. For example, a bill counter may determine the value of cash being placed into the container <NUM>. In an alternative example, a display may be provided in or on the container <NUM> to illustrate the content that is to be placed into the container <NUM>.

In operation <NUM>, the container <NUM> is locked. In example embodiments, the container <NUM> is locked using a digitally encoded lock mechanism entered by the sender <NUM>. The container <NUM> is then shipped to the recipient <NUM>.

At any time, the access key may be provided to the recipient <NUM>. For example, the access key may be provided by the sender <NUM>, the container <NUM>, or the central server <NUM> as soon as the container <NUM> is locked with the digitally encoded lock mechanism.

In another example, the access key may be provided when the container <NUM> arrives at a location that corresponds to a predetermined location of the recipient <NUM> (e.g., the shipping address of the recipient <NUM>). Accordingly, in operation <NUM>, a location signal may be provided (or caused to be provided) by the container <NUM>. For instance, when the container <NUM> arrives at the location corresponding to the recipient <NUM> (e.g., as determined by GPS), the container <NUM> may transmit the location signal to, for example, the central server <NUM> or the sender device <NUM>. In response to the location signal, the central server <NUM> or the sender device <NUM> may transmit the access key to the container <NUM> or the recipient device <NUM>. In other embodiments, the central server <NUM> or the sender device <NUM> my send a signal to unlock the container <NUM> in response to the location signal. Alternatively, when the container <NUM> is at the location of the recipient <NUM>, the container <NUM> may send the access key to or detect the access key from the recipient device <NUM> via Bluetooth.

In operation <NUM>, the access key is received. Subsequently, in operation <NUM>, a determination is made as to whether to unlock the container <NUM>. In one embodiment, the access key may be compared (e.g., at the container <NUM> or at the central server <NUM>) to the digitally encoded lock mechanism that was used to lock the container <NUM>. If there is a match, the determination is made to unlock the container <NUM> in operation <NUM>. In another embodiment, the access key may comprise an unlock signal received from the central server <NUM> or the recipient device <NUM> (e.g., based on results of a thumbprint analysis of the recipient <NUM> or location of the container <NUM> relative to the recipient).

Further still, the determination to unlock may be based on a multi-factor authentication process. For instance, the container may be unlocked in operation <NUM> based on the access key matching the digitally encoded lock mechanism and the container <NUM> be in a location corresponding to the recipient <NUM>. In other example, a three-factor authentication may require that the access key match the digitally encoded lock mechanism, the container <NUM> is at a location corresponding to the recipient <NUM>, and a biometric application (e.g., voice recognition application, retinal scan application, thumbprint application) verifies the recipient's identity.

If at operation <NUM>, a determination is made not to unlock the container <NUM> (e.g., the access key does not match the digitally encoded lock mechanism), then a determination is made in operation <NUM> whether a number of attempts to unlock the container <NUM> has exceeded a predetermined threshold. (e.g., three attempts). If the predetermined threshold is not exceeded, the method <NUM> returns to operation <NUM> to receive the access key again.

However, if the predetermined threshold is exceeded, then the container <NUM> is locked down in operation <NUM>. Once locked down, the container <NUM> may require a reset to be performed by an authorized agent (e.g., an agent of the security provider system) before attempts to unlock the container <NUM> may be made again. In an alternative embodiment, the lock down of the container <NUM> may occur based on a determination by the location module <NUM> (<FIG>) that the container <NUM> is not in a location corresponding to the recipient <NUM>.

<FIG> is a block diagram illustrating components of a machine <NUM>, according to some example embodiments, able to read instructions from a machine-readable medium e.g., a non-transitory machine-readable medium, a machine-readable storage medium, a computer-readable storage medium, or any suitable combination thereof) and perform any one or more of the methodologies discussed herein. Specifically, <FIG> shows a diagrammatic representation of the machine <NUM> in the example form of a computer system and within which instructions <NUM> (e.g., software, a program, an application, an applet, an app, or other executable code) for causing the machine <NUM> to perform any one or more of the methodologies discussed herein may be executed.

In alternative embodiments, the machine <NUM> operates as a standalone device or may be connected (e.g., networked) to other machines. In a networked deployment, the machine <NUM> may operate in the capacity of a server machine or a client machine in a server-client network environment, or as a peer machine in a peer-to-peer (or distributed) network environment. The machine <NUM> may be a server computer, a client computer, a personal computer (PC), a tablet computer, a laptop computer, a netbook, a set-top box (STB), a personal digital assistant (PDA), a cellular telephone, a smartphone, a web appliance, a network router, a network switch, a network bridge, or any machine capable of executing the instructions <NUM>, sequentially or otherwise, that specify actions to be taken by that machine. Further, while only a single machine is illustrated, the term "machine" shall also be taken to include a collection of machines that individually or jointly execute the instructions <NUM> to perform any one or more of the methodologies discussed herein.

The machine <NUM> includes a processor <NUM> (e.g., a central processing unit (CPU), a graphics processing unit (GPU), a digital signal processor (DSP), an application specific integrated circuit (ASIC), a radio-frequency integrated circuit (RFIC), or any suitable combination thereof), a main memory <NUM>, and a static memory <NUM>, which are configured to communicate with each other via a bus <NUM>. The processor <NUM> may contain microcircuits that are configurable, temporarily or permanently, by some or all of the instructions <NUM> such that the processor <NUM> is configurable to perform any one or more of the methodologies described herein, in whole or in part. For example, a set of one or more microcircuits of the processor <NUM> may be configurable to execute one or more modules (e.g., software modules) described herein.

The machine <NUM> may further include a graphics display <NUM> (e.g., a plasma display panel (PDP), a light emitting diode (LED) display, a liquid crystal display (LCD), a projector, or a cathode ray tube (CRT)). The machine <NUM> may also include an alpha-numeric input device <NUM> (e.g., a keyboard), a cursor control device <NUM> (e.g., a mouse, a touchpad, a trackball, a joystick, a motion sensor, or other pointing instrument), a storage unit <NUM>, a signal generation device <NUM> (e.g., a speaker), and a network interface device <NUM>.

The storage unit <NUM> includes a machine-readable medium <NUM> (e.g., a tangible and/or non-transitory machine-readable storage medium) on which is stored the instructions <NUM> embodying any one or more of the methodologies or functions described herein. The instructions <NUM> may also reside, completely or at least partially, within the main memory <NUM>, within the processor <NUM> (e.g., within the processor's cache memory), or both, during execution thereof by the machine <NUM>. Accordingly, the main memory <NUM> and the processor <NUM> may be considered as machine-readable media (e.g., tangible and/or non-transitory machine-readable media). The instructions <NUM> may be transmitted or received over a network <NUM> via the network interface device <NUM>. For example, the network interface device <NUM> may communicate the instructions <NUM> using any one or more transfer protocols (e.g., hypertext transfer protocol (HTTP)).

In some example embodiments, the machine <NUM> may be a portable computing device, such as a smart phone or tablet computer, and have one or more additional input components (e.g., sensors or gauges). Examples of such additional input components include an image input component (e.g., one or more cameras), an audio input component (e.g., a microphone), a direction input component (e.g., a compass), a location input component (e.g., a global positioning system (GPS) receiver), an orientation component (e.g., a gyroscope), a motion detection component (e.g., one or more accelerometers), an altitude detection component (e.g., an altimeter), and a gas detection component (e.g., a gas sensor). Inputs harvested by any one or more of these input components may be accessible and available for use by any of the modules described herein.

As used herein, the term "memory" refers to a machine-readable medium able to store data temporarily or permanently and may be taken to include, but not be limited to, random-access memory (RAM), read-only memory (ROM), buffer memory, flash memory, and cache memory. While the machine-readable medium <NUM> is shown in an example embodiment to be a single medium, the term "machine-readable medium" should be taken to include a single medium or multiple media (e.g., a centralized or distributed database, or associated caches and servers) able to store instructions. The term "machine-readable medium" shall also be taken to include any medium, or combination of multiple media, that is capable of storing instructions for execution by a machine (e.g., the machine <NUM>), such that the instructions, when executed by one or more processors of the machine (e.g., the processor <NUM>), cause the machine to perform any one or more of the methodologies described herein. Accordingly, a "machine-readable medium" refers to a single storage apparatus or device, as well as "cloudbased" storage systems or storage networks that include multiple storage apparatus or devices. The term "machine-readable medium" shall accordingly be taken to include, but not be limited to, one or more tangible (e.g., non-transitory) data repositories in the form of a solid-state memory, an optical medium, a magnetic medium, or any suitable combination thereof.

Furthermore, the machine-readable medium can be transitory in that it can embody a propagating signal.

The instructions <NUM> may further be transmitted or received over a network <NUM> using a transmission medium via the network interface device <NUM> and utilizing any one of a number of well-known transfer protocols (e.g., HTTP). Examples of communication networks include a local area network (LAN), a wide area network (WAN), the Internet, mobile telephone networks, POTS networks, and wireless data networks (e.g., WiFi and WiMAX networks). The term "transmission medium" shall be taken to include any intangible machine readable medium that is capable of storing, encoding, or carrying instructions for execution by the machine, and includes digital or analog communications signals or other intangible medium to facilitate communication of such software.

Certain embodiments are described herein as including logic or a number of components, modules, or mechanisms. Modules may constitute either software modules (e.g., code embodied on a machine-readable medium or in a transmission signal) or hardware modules. A "hardware module" is a tangible unit capable of performing certain operations and may be configured or arranged in a certain physical manner. In various example embodiments, one or more computer systems (e.g., a standalone computer system, a client computer system, or a server computer system) or one or more hardware modules of a computer system (e.g., a processor or a group of processors) may be configured by software (e.g., an application or application portion) as a hardware module that operates to perform certain operations as described herein.

In some embodiments, a hardware module may be implemented mechanically, electronically, or any suitable combination thereof. For example, a hardware module may include dedicated circuitry or logic that is permanently configured to perform certain operations. For example, a hardware module may be a special-purpose processor, such as a field programmable gate array (FPGA) or an ASIC. A hardware module may also include programmable logic or circuitry that is temporarily configured by software to perform certain operations. For example, a hardware module may include software encompassed within a general-purpose processor or other programmable processor.

Accordingly, the phrase "hardware module" should be understood to encompass a tangible entity, be that an entity that is physically constructed, permanently configured (e.g., hardwired), or temporarily configured (e.g., programmed) to operate in a certain manner or to perform certain operations described herein. As used herein, "hardware-implemented module" refers to a hardware module. Considering embodiments in which hardware modules are temporarily configured (e.g., programmed), each of the hardware modules need not be configured or instantiated at any one instance in time. For example, where a hardware module comprises a general-purpose processor configured by software to become a special-purpose processor, the general-purpose processor may be configured as respectively different special-purpose processors (e.g., comprising different hardware modules) at different times. Software may accordingly configure a processor, for example, to constitute a particular hardware module at one instance of time and to constitute a different hardware module at a different instance of time.

Although an overview of the inventive subject matter has been described with reference to specific example embodiments, various modifications and changes may be made to these embodiments without departing from the broader scope of embodiments of the present invention. Such embodiments of the inventive subject matter may be referred to herein, individually or collectively, by the term "invention" merely for convenience and without intending to voluntarily limit the scope of this application to any single invention or inventive concept if more than one is, in fact, disclosed.

Claim 1:
A processor implemented method at a container (<NUM>), the method comprising:
determining by a code module (<NUM>) of the container (<NUM>), a digitally encoded lock mechanism, that is used by a sender for locking the container (<NUM>) after placement of content into the container (<NUM>); causing the locking of the container (<NUM>) after placement of the content into the container (<NUM>) and before shipping of the container (<NUM>) to a recipient (<NUM>);
sending by the container (<NUM>), an access key to a recipient device (<NUM>) upon delivery of the container (<NUM>) to the recipient (<NUM>) and when the container (<NUM>) is within a range of the recipient device (<NUM>);
receiving the access key from the recipient (<NUM>) that receives the container (<NUM>);
causing an authentication process to be performed that determines whether the access key triggers unlocking of the container (<NUM>); and
based on a determination that the access key triggers the unlocking of the container (<NUM>), causing the container (<NUM>) to unlock.