Method and apparatus for sharing content data between networked devices

A system and method for sharing content data between networked devices in communication with a server processor circuit via a data network is disclosed. The method involves, in response to a request received at the server from a first networked device to upload content data, causing the content data to be written to a storage location at a content storage address. The method also involves causing the server processor circuit to store the content storage address in a database managed by the server. The method further involves causing the server processor circuit to associate an access key with the content storage address in the database and to determine and store an expiry for the access key in the database, the expiry facilitating a determination as to whether the access key remains actively associated with the content data or has expired and is no longer associated with the content data. The method also involves receiving a content access request at the server from a second networked device to access the content data uploaded by the first networked device, the content access request including a request access key. The method further involves causing the server processor circuit to perform a database query and if there is an unexpired access key in the database that matches the request access key, authorizing the second networked device to access the content data.

BACKGROUND

This disclosure relates generally to methods for sharing content data between networked devices in communication with a server processor circuit via a data network.

2. Description of Related Art

Sharing of digital content via networked devices such as smartphones, data tablets, laptop and desktop computers and other networked devices has become prevalent. Users share data content for social or commercial purposes. The uploaded content may be stored in a storage location accessible via a data network having a network address. However, in many instances accessing uploaded content may be hampered by practicalities since the storage address may be long and difficult to enter without making a mistake. There remains a need for providing easy access to content that has been uploaded.

SUMMARY

In accordance with one disclosed aspect there is provided a server implemented method for sharing content data between networked devices in communication with a server processor circuit via a data network. The method involves, in response to a request received at the server from a first networked device to upload content data, causing the content data to be written to a storage location at a content storage address. The method also involves causing the server processor circuit to store the content storage address in a database managed by the server. The method further involves causing the server processor circuit to associate an access key with the content storage address in the database and to determine and store an expiry for the access key in the database, the expiry facilitating a determination as to whether the access key remains actively associated with the content data or has expired and is no longer associated with the content data. The method also involves receiving a content access request at the server from a second networked device to access the content data uploaded by the first networked device, the content access request including a request access key. The method further involves causing the server processor circuit to perform a database query and if there is an unexpired access key in the database that matches the request access key, authorizing the second networked device to access the content data.

Causing the server processor circuit to determine the expiry for the access key may involve setting an expiry for the access key at about 90 days from a date of association of the access key.

The method of may further involve, in response to receiving a request from a user of the first networked device, causing the server processor circuit to extend the expiry of the access key by an additional time period.

The access key may include an alphanumeric keyword, the keyword having a length of less than 20 characters.

The request to upload content data may include a user identification of a user of the first networked device, and may further involve performing a user authentication prior to uploading the content data to the storage location.

The method may involve storing and associating the user identification of the user of first networked device with the content storage address of the content data in the database.

Causing the content data to be written to the storage location may involve receiving the content data from the first network device at the server, and causing the content data to be written to the storage location may involve writing the content data to a network storage location accessible via the data network and having a network storage address.

The method may involve processing the received content data prior to writing to the network storage location, and the processing may involve at least one of determining a data size associated with the content, establishing compliance with criteria for storage of the content data in the network storage location, performing a virus scan on the content data, performing a malware scan on the content data, or encrypting the content data.

The database may include a plurality of stored keywords, each keyword being a unique and meaningful alphanumeric word or phrase and associating the access key with the content data may involve selecting a keyword in the database that either has not yet been associated with content data or has expired and is no longer associated with the content data.

Associating the access key with the content data may involve receiving access key data from the first networked device and storing the access key data in the database.

The method may involve causing the server processor circuit to extend the expiry beyond an access key lifetime for an access key based on access key data received from a networked device.

Determining expiry for the access key may involve one of calculating an expiry time based on an access key lifetime and storing the expiry time in the database, storing in the database, a time of day when the access key was associated with the content data in the database, and calculating an expiry time based on a pre-determined access key lifetime, calculating an expiry time based on an access key lifetime, the access key lifetime selected from a plurality of pre-determined access key lifetimes associated with different levels of user membership, and storing the expiry time in the database, or calculating an expiry time based on a number of characters in an access keyword may involve a plurality of alphanumeric characters.

Associating the access key with the content data may involve associating an image with the content data, the image may involve one of image data extracted by the server from the content data, image data uploaded by the first networked device for associating with the content data, a barcode, QR code, or other encoded pattern assigned by the server, or a barcode, QR code or other encoded pattern uploaded by the first networked device for associating with the content data.

The method may involve causing the server processor circuit to generate a content identifier and to store and associate the content identifier in the database with at least one of the content storage address and the associated access key.

Causing the server processor circuit to store the content storage address may involve storing a content record to a content table in the database, the content record including the content storage address and the content identifier and associating the access key with the content storage address may involve storing the content identifier in an access key record in an access key table in the database, the access key record further including the access key and the expiry associated with the access key.

The method may involve causing the server processor circuit to generate and associate a status with the content data, the status being indicative that the content data is owned by a user of the first networked device.

The method may involve, in response to a request from the first networked device, querying the database to extract information associated with all content data uploaded by the user of the first networked device and transmitting the information for display on the first networked device.

The method may involve in response to a requested change to the information associated with the content data received from the user of the first networked device, causing the server processor circuit to make the requested change to the information associated with the content data in the database.

The method may involve receiving from the first networked device, a privacy indicator indicating that the content data should be only accessible on a private basis by users that have been granted permission by a user of the first networked device, and storing and associating the privacy indicator with the content storage address for the content data.

The method may involve generating additional metadata for the content data and storing and associating the metadata with the content storage address for the content data, the additional metadata including at least one of a user name associated with a user of the first device, a data size of the networked content, a content data title associated with the content data, or a content data description associated with the content data.

The access request may further include an identification of a user of the second networked device, and the method may further involve performing a user authentication prior to causing the server processor circuit to perform the database query to determine if there is an unexpired access key in the database that matches the request access key.

The request access key in the access request may involve one of a unique and meaningful alphanumeric keyword or phrase entered by the user of the second networked device, alphanumeric text extracted from an image having the keyword digitally encoded therein, the image being captured and processed by the second networked device to extract the alphanumeric text, alphanumeric text extracted by performing speech recognition on audio data, the audio data being captured and processed by the second networked device to extract the alphanumeric text.

Receiving the access request may involve receiving an access key including an image related to the content data, and the method may further involve causing the server to process the image to extract an identifying feature and causing the server processor circuit to query the database may involve causing the server to determine whether an access key stored in the database has a matching identifying feature.

The identifying feature may involve one of a keyword extracted from the image by causing the server processor circuit to perform optical character recognition on the image, or a pattern extracted from the image by causing the server processor circuit to perform a rendering process on the image.

Authorizing the second networked device to access the content data may involve causing the server processor circuit to query the database to determine whether the content data has a privacy indicator indicating that the content data should be only accessible on a private basis by users that have been granted permission by a user of the first networked device, and if the privacy indicator indicates that the content data is not only accessible on a private basis, causing the server processor circuit to store a status indicator in the database indicating that the content data is shared with the user of the second networked device.

Authorizing the second networked device to access the content data may involve causing the server processor circuit to query the database to determine whether the content data has privacy indicator indicating that the content data should be only accessible on a private basis by users that have been granted permission by a user of the first networked device, if the privacy indicator indicates that the content data is only accessible on a private basis, causing the server to generate a notification for transmission to the user of the first networked device indicating that a user of the second networked device has requested access to the content data, and in response to receiving sharing permission from the user of the first networked device to share the content data, causing the server processor circuit to store and associate a status indicator in the database with the content storage address of the content data, the status indicator being indicative that the content data is shared with the user of the second networked device.

The method may involve in response to a request from the second networked device, querying the database to extract information associated with all content data shared with the user of the second networked device and transmitting the information for display on the second networked device and the method may further involve in response to receiving a selection from the second networked device of an item of content data shared with the user, causing the processor to download the content data from the storage location and to transmit the content data to the second networked device.

The content data may include a presentation file and the access key may include one of an image of a portion of the presentation file displayed during a live presentation, a keyword displayed during a live presentation, or a keyword included in materials related to the presentation.

The content data may include information associated with an item that is available for purchase and the access key may include one of a vehicle identification number for a vehicle, a captured image of a plate bearing the vehicle identification number, alphanumeric characters of a vehicle registration plate on a vehicle, a captured image of the vehicle registration plate, or a listing number of a property for sale.

In accordance with another disclosed aspect there is provided a server apparatus for sharing content data between networked devices in communication with the server via a data network. The apparatus includes a server processor circuit, a storage location accessible by the server processor circuit, and a database managed by the server. The server processor circuit is operably configured to, in response to a request received at the server from a first networked device to upload content data, cause the content data to be written to the storage location at a content storage address, store the content storage address in the database, and associate an access key with the content storage address in the database. The server processor circuit is also operably configured to determine and store an expiry for the access key in the database, the expiry facilitating a determination as to whether the access key remains actively associated with the content data or has expired and is no longer associated with the content data. The server processor circuit is further operably receive an access request at the server from a second networked device to access the content data uploaded by the first networked device, the access request including a request access key, and perform a database query and if there is an unexpired access key in the database that matches the request access key, authorize the second networked device to access the content data.

Other aspects and features will become apparent to those ordinarily skilled in the art upon review of the following description of specific disclosed embodiments in conjunction with the accompanying figures.

DETAILED DESCRIPTION

Referring toFIG.1, a system for sharing content data is shown generally at100. The system100includes a server102having a server processor circuit104. In one embodiment the server102may be one of a plurality of servers or a virtual server made available in a server farm106, such as the on-demand cloud computing platforms provided by Amazon Web Services (AWS). The server102or server farm106is in data communication with a data network108such as the Internet. The server102is also in communication with a storage location110, which may be a cloud storage service such as Amazon Simple Storage Service (Amazon S3) offered by Amazon Web Services that provides object storage through a web service interface at a storage address accessible via the data network108. In other embodiments the storage location110may be implemented using local storage associated with the server102.

In this embodiment the system100also includes a networked database112which is accessible via the data network108. In one embodiment the networked database112may be implemented as a MongoDB, which is a document-oriented database program. In other embodiments the networked database112may be hosted on one or more of the servers in the server farm106.

A plurality of other networked devices are also in data communication with the data network108. In the embodiment shown a first networked device114in use by a first user116is wirelessly connected to the data network108. The wireless connection may be an IEEE 804.11 Wi-Fi connection, Bluetooth connection, or a cellular data connection, for example. In the embodiment shown the first networked device114is a smartphone device. A second networked device118, also a smartphone, is in use by a second user120and is wirelessly connected to the data network108. In the embodiment shown a third networked device in the form of a laptop computer122is connected to the data network108via a wired connection. The first networked device114, the second networked device118, and the laptop computer122are thus each able to transmit or upload data to the server102via the data network108and receive or download data via the data network.

A block diagram of the server processor circuit104is shown inFIG.2. Referring toFIG.2the processor circuit104includes a microprocessor200, a program memory202, a variable memory204, and an input output port (I/O)206, all of which are in communication with the microprocessor200. Program codes for directing the microprocessor200to carry out various functions are stored in the program memory202, which may be implemented as a random access memory (RAM), and/or a solid state or hard disk drive, or a combination thereof. The code may be written in any suitable program language, such as Javascript, Python, Java, C, C++, C#, and/or assembly code, for example. The program memory202includes a block of program codes220for directing the microprocessor200to perform operating system functions. The program memory202also includes a block of codes222for directing the microprocessor200to provide content sharing functions, a block of codes224for directing the microprocessor to perform optical character recognition, image rendering, or speech recognition functions, and a block of codes226for providing use authentication services. The program memory202also includes a block of codes228for directing the microprocessor200to provide database functions, and a block of codes230for directing the microprocessor200to provide content storage and retrieval functions.

In the embodiment shown inFIG.2, the processor circuit104further includes a mass storage unit240providing data storage for storing content data and other data associated with providing content sharing functions. In one embodiment the mass storage unit240may be implemented using one or more hard drive units, solid state drives, or other persistent storage medium such as a magnetic tape storage unit. The mass storage unit240may provide storage for a number of different types of data items such as short term storage for content data242while being uploaded. The mass storage unit240may in some embodiments provide storage for database tables including a metadata table244, an access key table246, user tables248, and a notifications table250. In other embodiments the database tables244-250may be stored in the networked database112as shown inFIG.1.

The I/O206includes a communications interface260for conducting data communications over the data network108. The I/O206also includes a storage interface262for interfacing with the mass storage unit240.

Although the processor circuit104is shown inFIG.2as having conventional computer architecture, the processor may be implemented using shared configurable computer system resources such as may be provided by companies such as Microsoft, Google, or Amazon and other cloud computing resource providers. As such, the processor circuit104shown may represent a virtual machine, possibly implemented using multiple processors and other resources to provide the necessary functionality. One advantage of using a shared computing resource is that the resource becomes dynamically scalable and additional processing power or storage may be allocated as required. As such, the microprocessor200, program memory202, variable memory204, and I/O206, may be parts of a virtual machine hosted on a shared and/or distributed computing resource.

A block diagram of a processor circuit for implementing any of the devices114,118, or122is shown generally at300inFIG.2. Referring toFIG.2, the processor circuit300includes a microprocessor302, a display304, and an input device306for receiving user input. In some embodiments the input device306may be provided as touch screen on the display304. The processor circuit300also includes a memory310for storing data associated with operating system functions and/or applications that are running on the device. The memory310may be implemented using random access memory, non-volatile flash memory, a hard drive or combination of these and other memory types. The memory310may be used for storing program codes and/or data and in the embodiment shown includes an operating system storage location312, a content sharing application storage location314for storing program codes for implementing content sharing application on the device, and a data storage location316for storing content data.

The processor circuit300further includes a RF baseband radio320and antenna322for connecting to a mobile telecommunications network. The RF baseband radio320may be configured to provide data communications using any of a variety of communications standards including 2G, 3G, 4G, and/or 5G or any other communications standards. The processor circuit300also includes a wireless radio324and antenna326for connecting to local networks such as an IEEE 804.11 Wi-Fi local network. The wireless radio324may also provide for connections via other wireless links or protocols, such as Bluetooth, Wi-Fi Direct, or near-field communication. The processor circuit300further optionally includes a location receiver328. The location receiver328includes an antenna330for receiving global positioning system (GPS) signals and the location receiver may use the GPS information in combination with other location information such as a known location of a particular local network access point or cellular signal triangulation information provided by a cellular service provider to determine a location of the networked device. The processor circuit300further includes an audio processor332, a microphone334, and a speaker336. The audio processor332receives and processes audio input signals from the microphone334and produces audio outputs at the speaker336. The processor circuit300also includes a video/image processor338and a camera340. The video/image processor338receives and processes image and/or video signals from the camera340. The display304, input device306, memory310, RF baseband radio320, wireless radio324, location receiver328, audio processor332, and video/image processor338are all in communication with the microprocessor302.

The operating system storage location220stores codes for directing the microprocessor302to implement an operating system, which for the smartphone devices114and118may be an Android™ based operating system, an iOS based operating system, or any other operating system. The laptop computer122may be running an Android, iOS, Windows®, Linux, or any other suitable operating system.

Each of the devices114,118, and122may be implemented using the processor circuit300or similar processor circuit. The laptop computer device122may include many of the components of the processor circuit300shown inFIG.3, although some components may be omitted such as the location receiver328and RF baseband radio320. While embodiments are described herein with reference to the processor circuit architecture300shown inFIG.3, the described system embodiments and/or process embodiments are also applicable to communications between other types of devices capable of connecting to the data network108.

Uploading Content Data

Referring toFIG.4A, a flowchart depicting blocks of code for directing the processor circuit300of the first networked device114to initiate an upload of content to the server processor circuit104is shown generally at400. A flowchart depicting blocks of code for directing the server processor circuit104to receive and process the uploaded content is shown generally at420. The blocks generally represent codes that may be read from the program memory202of the server processor circuit104or memory310of the networked device processor circuit300for directing the respective microprocessors200and302to perform various functions for uploading content. The actual code to implement each block may be written in any suitable program language, such as C, C++, C#, Java, JavaScript, and/or assembly code, for example.

The device upload process400starts at block402when the user116of the first networked device114causes the block of codes314in the memory310of the processor circuit300to be executed, which launches the content sharing application on the first networked device. The content sharing application may run as a stand-alone application or as a web application that runs within a browser window running on the first networked device114.

The server upload process420begins at block422, which directs the microprocessor200of the server102to determine whether a request to connect has been received from the first networked device114. If a request to connect has not been received, block422is repeated. If a request to connect is received from the first networked device114, block422directs the microprocessor200to block424. Block424directs the microprocessor200to establish a Transmission Control Protocol (TCP) connection between the server102and the first networked device114via the communications interface260and the data network108. Block426then directs the microprocessor200to transmit an initial screen to the first networked device114.

The device upload process400then continues at block404, which directs the microprocessor302to display the initial screen on the display304. Referring toFIG.5A, the initial screen displayed on the display304of the first networked device114is shown at500as a screenshot. The screen500includes fields and options for logging the user116of the first networked device114into the application. In this example, block404further directs the microprocessor302to request the user116to provide credentials such as a user identification (in the form of an email address in this case) and a password, or login using social media credentials. In some embodiments the user identification of the user116of the first networked device114may be transmitted to the server processor circuit104, which may perform a user authentication of the user prior to providing content sharing services to the first networked device. Block404then directs the microprocessor302to transmit the user credentials to the server102.

The server upload process420then continues at block428, which directs the microprocessor to verify the credentials of the user116of the first networked device114against account information previous set up by the user. If the credentials are not verified at block428, the microprocessor200is directed to notify the first networked device114of the incorrect user credentials and retransmit the initial screen. Block428is then repeated. If at block428the user credentials are verified, then the microprocessor200is directed to block430. Block430directs the microprocessor200to open a WebSocket connection between the server102and the second networked device118. The WebSocket connection facilitates two-way communication of data between the second networked device118and the server102via the TCP connection and allows notifications to be pushed to the second networked device118for display on the display304. The WebSocket connection is established for communications only between the server and the first networked device114. Each user of a networked device that launches and logs in to the application would thus have a separate WebSocket connection established between the networked device and the server102. Block430then directs the microprocessor200to transmit an upload screen to the first networked device114. The server upload process420then continues at block432onFIG.4B.

The device upload process400continues at block406, which directs the microprocessor302of the first networked device114to display the upload screen received from the server102. The upload screen is shown inFIG.5Aas a screenshot. The screen502displays a link504for initiating the upload, which when selected or clicked by the user116causes a pop-up box506to be displayed, prompting the user to select content such as a photo or to browse saved content on the device. The process then continues at block408onFIG.4B.

Referring toFIG.4B, block408of the process400directs the microprocessor302to determine whether the user116of the first networked device114has initiated a request to upload content data. If at block408, there is no request to upload content data, block408is repeated. If a request to upload content has been initiated at block408, the microprocessor302is directed to transmit the request to the server102over the TCP connection. Block408then directs the microprocessor302to block410.

The server upload process420then continues at block428, which directs the microprocessor200to determine whether a request to upload content data has been received, and if not the microprocessor is directed to repeat block428. If a request is received, block428directs the microprocessor200to block430, which directs the microprocessor to upload and process the content data. In one embodiment, block430directs the microprocessor200to receive the content data uploaded over the data network108at the communications interface260. Block430may also direct the microprocessor200to perform additional processing of the content data, such as determining a data size associated with the content and/or establishing compliance with criteria for storage of the content data in the network storage location110. Block430may also direct the microprocessor200to perform a virus scan and/or malware scan on the content data. In some embodiments the content data may further be encrypted in accordance with the user's preferences to prevent unauthorized access.

In this embodiment block430further directs the microprocessor200to transmit updates to the first networked device114indicating a status of the upload and facilitating display of the a graphic510on the screen508.

The device upload process400then continues at block410, which directs the microprocessor302to determine whether the upload is completed. As disclosed above, the server102may transmit upload status messages to the first networked device114, which may be used to monitor upload progress. Referring toFIG.5C, a screen displayed on the display304of the first networked device114is shown at508as a screenshot and includes a graphic510indicating upload progress.

The process420then continues at block432, which directs the microprocessor200to write the content data to a storage location. In embodiments, where the content data is to be stored in the network storage location110, block432directs the microprocessor200to access the network storage in accordance with the network storage protocols. Network storage providers generally make application programming interface (API) available to subscribers that can be programmatically accessed for storing data to the storage location. Block432directs the microprocessor200to determine a storage address or URL (uniform resource locator) for writing and accessing the content data at the storage location110. The storage address will typically include a portion identifying the network storage location on the data network108, a portion identifying a bucket or storage resource assigned to the server102, and a portion identifying the content data (for example “image.jpg”). Block432then directs the microprocessor200to access the storage API and to write the content data to the network storage location110at a location corresponding to the storage URL. If the API returns a status indicating that the write operation to the storage location110was successful, the process continues at block434.

The content data store242in the mass storage unit240may only be used for short-term storage of content data while being processed in accordance with block430. However, in other embodiments, the content data may be stored in the local content data store242of the mass storage unit240on a longer term basis.

Block434then directs the microprocessor200to generate metadata for the uploaded content data now stored in the storage location110. In one embodiment the metadata is stored in a metadata database table244hosted by the networked database112. An example of a metadata table is shown inFIG.6Aat600. The metadata table600shown is configured for use with a Mongo DB and employs a JavaScript Object Notation (JSON) format. The metadata table600includes records602-610, each of which is associated with a particular content data item in the storage location110and includes a plurality of data fields for holding metadata information associated with the associated data item. The metadata record602is associated with the content uploaded at block432. Block434then directs the microprocessor200to generate a content_id, which is stored in a field612of the metadata record602. In this embodiment the content_id is an alphanumeric string having 9 characters, which is randomly generated and uniquely associated with the content data uploaded at blocks428-432. Block434further directs the microprocessor200to store the storage address of the content data in an address field614of the metadata record602. The storage address or URL would have been generated by the server102when writing the content data to the storage location110. In this case the address is for a content data item “Image.jpg”, which is stored in a “Linkme” bucket in Amazon S3 storage.

Block434then directs the microprocessor200to save a user identifier in an owner field616of the metadata record602. As noted above, when the screen500inFIG.5Ais displayed, the user116will have entered information such as an email address that permits the server to identify the user116of the first networked device114. In some embodiments the server102will also allow the user116to associate their name with their email address. In this example the content data is owned by a user having a name of “Tom Stevens”.

Block434further directs the microprocessor200to save the data size of the uploaded content data in a size field618of the record602. As disclosed above, the processing at block430may involve determine a data size of the content data item uploaded by the second networked device118. Block434also directs the microprocessor200to store an indication of the type of content data stored in the storage location110in a data type field620of the metadata record602. A variety of different types of content may be uploaded and identified by the extension appended to the file (for example “.jpg” for a “JPEG” (Joint Photographic Experts Group) type image file. In this embodiment the metadata record602also includes additional fields622-626which will be described later herein.

The process420then continues at block436, which directs the microprocessor200to associate an access key with the content data. In one embodiment the access key is selected form the access key table246in the networked database112. An example of an access key table in JSON format is shown inFIG.6Bat630. The access key table630includes a plurality of access key records632-634, each including a plurality of data fields for holding information associated with a particular access key. For example, in the embodiment shown the access key record632includes an access key field642for holding an alphanumeric access keyword. In this embodiment the keyword is a meaningful word “Yerevan”. The access key record632also includes a field644for holding the content_id, as described above in connection with the field612of the record602in the metadata table600. The access key record632also includes a content_id field644and an expiry field646. In this embodiment the expiry field646includes a date and a time in 24-hour time format.

Block436of the process420also directs the microprocessor200to determine a current date and time and then select a first record from the access key records632-640that has an expiry field prior to the current date. In one embodiment the access key table630in the networked database112may be pre-populated with a large number of records having unique access key values with the expiry set to the current date and time. Once an expired access key is found in the access key table630, block436further directs the microprocessor200to determine and store an expiry for the access_key642in the expiry field646in the access key table630. The expiry field646facilitates a determination as to whether the access key remains actively associated with the content data or has expired and is no longer associated with the content data. The expiry may be calculated on the based on a pre-determined or otherwise determined time period during which the access_key642is to be associated with the content data. As an example, the access_key642may be set to expire 24 or 48 hours after being associated with the content data. In another embodiment, users of the content sharing implemented by the server102may be able to sign up for a paid premium membership that entitles them to a longer time period before the access key expires, for example 90 days.

In other embodiments, the user116of the first networked device114may request the server102to extend the expiry of the access key642by an additional time period. For example, a user116having a paid membership may be permitted to extend the expiry of an access key for an additional 90 days on request to the server102.

In some embodiments, the user116may be permitted to select their own alphanumeric keyword for use as an access key and expiry of the access key may be made dependent on a number of characters in the keyword. For example, shorter keywords like “Dog”, “File”, etc. may be set to expire within a few days, while longer keywords like “Vacation Photographs”, which has 20 characters would be set to expire after a longer time period, for example after a week.

Referring again toFIG.6B, the access key field642in this access key record632indicates that the access key “Yerevan” has been associated with the content data defined in the metadata record602that has the same content_id612corresponding to the content_id in the field644of the access key table630. The access_key “Yerevan” has also been set to expire on Mar. 30, 2019 at 11:21.

The process420then continues at block438, which directs the microprocessor200to update a user table in the networked database112for the owner of the content data. An example of a user table for the user116Tom Stevens in JSON format is shown inFIG.6Cat650. The user table650includes a plurality of records. A record652includes a content_id field654that corresponds to the content_id fields644in the access key table630and content_id field612in the metadata table600. The record652also includes an owner field656for holding an indication (i.e. “owner”) that the content referenced in the content_id field654is owned by the user associated with the user table. Other user tables will also be generated for users of other devices such as the networked devices118and122shown inFIG.1. For example, the user120of the second networked device118is named John Smith, and has had a user table660shown inFIG.6Dgenerated having records662and664. In the record662of the user table660has a status field670set to “shared”, indicating that the user120is not the owner of the content data referenced in a content_id field668of the record. The server upload process420then continues at block440, which directs the microprocessor200to transmit the access key “HyKiJyOcm” to the first networked device114.

The device upload process400then resumes at block408, where having received the access key indicating that the upload is complete, the microprocessor302is directed to block410. Referring toFIG.5D, a screen displayed on a display304of the first networked device114when the upload has completed is shown at512as a screenshot. The screen512includes an indication514confirming that the upload has completed and a box516that displays the access key “Yerevan”. At this stage the content data has been uploaded, saved in the storage location110, and the networked database112tables updated. However the user116of the first networked device114may optionally provide additional input for association with the uploaded content data. The screen512includes an input box518for receiving a file title, an input box520for receiving a file description, a checkbox522for indicating whether the content data should be made “private”, and a save button524for causing changes to the content to be saved.

The device upload process400then continues at block414, which directs the microprocessor302to determine whether the save button524has been selected by the user116of the first networked device114. If the save button524has been activated, the microprocessor302is directed to block416which directs the microprocessor to transmit changes to the information in the input boxes518and520, or a change to the privacy checkbox522to the server102. The process then continues at block418, which directs the microprocessor302to display a content dashboard for listing content available to the user116, which is described in more detail below.

The server upload process420continues at block442, which directs the microprocessor200to determine whether a “save” message has been received from the first networked device114. If a save message has been received, block442directs the microprocessor200to block444, which directs the microprocessor to update the optional file information and/or the privacy setting. Referring back toFIG.6A, the record602of the metadata table600includes a public_private field622for holding a value indicating whether the content is to be accessible by all other users or maintained private and only accessible to users permitted by the user116of the first networked device114to access the content. In one embodiment this field may be initially populated with a default value (for example “private”), which will be active unless the user116of the first networked device114changes the value. The metadata record602also includes a file_tide field624and the file_description field626for holding optional file title and description values provided by the user116. When the save message includes a user privacy selection, block444directs the microprocessor200to write the privacy selection value to the public_private field622(in this case “private”). Similarly, if the save message includes a file title or file description, block444directs the microprocessor200to write these values to the file_tide field624and file_description field626. The microprocessor200is then directed back to block428to await a further content data upload.

If at block414of the process400, the save button524is not activated by the user116and the screen512is simply closed by the user (for example by closing a browser window displaying the screen), then the microprocessor302is directed to block418and the content dashboard is displayed. In this case the content data is saved with a default privacy setting (typically the content data will be public), and without any additional file information. If at block442of the server upload process420, no save message is received at the server then the microprocessor200is directed back to block428, to await a further content data upload.

Referring toFIG.7, a content dashboard screen displayed on any of the devices114,118, or122is shown at700as a screenshot. In one embodiment, the content dashboard screen700is displayed when the user116activates the save button524. Alternatively, the screen700may be a first screen displayed to the user116after the login screen500has been displayed and the user116has entered their credentials. The content dashboard screen700includes a listing of content items702. The listing702includes a content name column704, a content size column706, a privacy setting column708, an access key column710, and an actions column712. The actions column712includes a plurality of “delete” buttons714associated with each item in the listing702. The privacy setting column708includes a plurality of privacy controls716associated with each item in the listing702. The content dashboard screen700has two tabs including a first tab718and a second tab720. In the example shown inFIG.7, the first tab718is underlined to show that the listing702below is associated with files owned by the user116“Tom Stevens”. The second tab720, when activated, will show a listing (not shown) of content data currently being shared by other users with the user116“Tom Stevens”. The content dashboard screen700also includes an “upload” button722, which when activated by the user116initiates the content data upload process400described above. The content dashboard screen700also includes an “access a file” button724, which when activated initiates a content data access process described later herein.

In the above embodiment the access key has been described with reference to an alphanumeric keyword, which can be represented as a character string in the access key table630stored in the networked database112. The alphanumeric keyword may include common words, letter sequences, number sequences such as a telephone number, and mixed letter and number sequences such as a vehicle license plate or portion of an address. In other embodiments the access key may be otherwise implemented, as described later herein.

Content Dashboard

Referring toFIG.8A, a flowchart depicting blocks of code for directing the processor circuit300of the first networked device114to implement block418of the process400for displaying the content dashboard is shown generally at800. The dashboard display process800begins at block802, which directs the microprocessor302to transmit a request to the server102for updated content dashboard data. A process implemented at the server102to handle the request for updated content dashboard data is shown at830. The server dashboard update process830begins at832, which directs the microprocessor200to determine whether a request for content dashboard data has been received. If no request is received, block832directs the microprocessor200to repeat block832. If at block832, a request has been received, the microprocessor200is directed to block834. As noted above, the content dashboard screen700includes the first tab718for listing content data uploaded and owned by the user116of the first networked device114and a second tab720for listing shared content data. In one embodiment, the content dashboard screen700is initially displayed with the first tab718activated. Block834directs the microprocessor200to determine whether the user116has requested display of data owned by the user, in which case the microprocessor is directed to block836. Block836directs the microprocessor200to query the user table for the user Tom Stevens shown inFIG.6Cto select all records having the status field656set to “owner” (in this case all three records).

If at block834, the display of data shared with the user116by other users is requested, the microprocessor200is directed to block838. Block838directs the microprocessor to query the user table shown in FIG.6C to select all records having the status field656set to “shared”. In this example, the user116has no shared content data.

Following execution of either block836or836, a set of content_id values would have been selected and the process830then continues at block840. Block840directs the microprocessor200to query the metadata table for records corresponding to the set of selected content_id values. Block840directs the microprocessor200to extract values for the field_title field624, size field618and the public_private field622. Block840also directs the microprocessor200to query the access key table630(FIG.6B) for records corresponding to the set of selected content_id values and to read any access_key values642that have not yet expired. This step involves the microprocessor200comparing the expiry field646for each matching record to the current date and time to determine whether the access_key642value is still active.

The server dashboard update process830then continues at block842, which directs the microprocessor200to transmit content dashboard data to the first networked device114. The listing data will include, for each selected content_id value, the file_title value624, the size value618, the public_private value622, and the access key value642(if still unexpired) all read from the metadata record602. If the access key had already expired there would be little point in reading and transmitting this value to the user. Block844then directs the microprocessor200to block844inFIG.8B.

The dashboard display process800then continues at block804when content dashboard data is received at block804and the microprocessor302is directed to block806. Block806directs the microprocessor302is to display the data in the columns704-710as shown inFIG.7. Block808then directs the microprocessor302to determine whether the “Shared with Me” second tab720has been activated, in which case the microprocessor is directed back to block802and a request for updated content dashboard data is transmitted as described above. If at block808, the “Shared with Me” second tab720has not been activated then the process continues at block810, which directs the microprocessor302to determine whether the “My files” first tab718has been activated. If the first tab718has been activated, block810directs the microprocessor302back to block802and a request for updated content dashboard data is transmitted as described above.

If at block810, the second tab720has not been activated then the process continues at block812, which directs the microprocessor302to determine whether the “upload” button722has been activated. If the “upload” button722has been activated, block812directs the microprocessor to block408of the device upload process400shown inFIG.4, and the upload process is executed as described above.

If at block812, the “upload” button722has not been activated then the process continues at block814, which directs the microprocessor302to determine whether the “access a file” button724has been activated. If the “access a file” button724has been activated, block814directs the microprocessor to block904of a content access request process900shownFIG.9A(described later herein). If at block814, the button724has not been activated then the process continues at block816onFIG.8B.

Referring toFIG.8B, block816directs the microprocessor302to determine whether any of the plurality of privacy controls716has been activated, in which case the microprocessor is directed to block818. Block818directs the microprocessor302to transmit a request to the server102to change the privacy for the associated item in the listing702. The server dashboard update process830then continues at block844, which directs the microprocessor200of the server102to determine whether a request has been received from the first networked device114to change the public_private field622in the metadata record602in the metadata table600. If a request to change the public_private field622has been received, block844directs the microprocessor200to block846. Block846directs the microprocessor200to determine whether the user116of the first networked device114is the owner of the content data identified in the request. In one embodiment, block846directs the microprocessor200to read the owner field616in the metadata record602metadata record602in the metadata table600to determine whether the user of the first networked device114making the request matches the value in the owner field616. Alternatively, block846could direct the microprocessor200to query the user table650for the user making the request (for example, Tom Stevens) to determine whether the content data item in the table has the status field656set to “owner”. In either case, if the user making the request is the owner of the content data then the process continues at block848. Block848directs the microprocessor200to update the public_private field622in the metadata record602in the metadata table600to reflect the requested change.

The dashboard display process800then continues at block820if either block818has completed, or if at block816it is determined that no change to the privacy settings is required. Block820directs the microprocessor302to determine whether any of the plurality of “delete” buttons714has been activated. If none of the plurality of “delete” buttons714has been activated, block820directs the microprocessor302back to block802inFIG.8Aand the dashboard display process800is repeated. If one of the plurality of “delete” buttons714has been activated, the microprocessor302is directed to block822, which directs the microprocessor to transmit a request to delete the associated content item to the server102. The microprocessor302is then directed back to block802inFIG.8Aand the dashboard display process800is repeated.

The server dashboard update process830then continues at block850, which directs the microprocessor200of the server102to determine whether a request to delete a content item has been received from the first networked device114. If a request to delete a content item has been received, block850directs the microprocessor to block852, which directs the microprocessor to determine whether the user116of the first networked device114is the owner of the content data identified in the request. If the user making the request is the owner of the content data then the process continues at block854. Block854directs the microprocessor200to set expiry field646in the record632of the access key table630to the current date and time, such that the access key will remain in the networked database112as an available expired access key. Block854also directs the microprocessor200to read the address in the address field614of the metadata record602in the metadata table600and to delete the corresponding content data located in the networked database112at the storage address. Block854then directs the microprocessor to delete the entire metadata record602. Finally block854also directs the microprocessor to update the user table650for the user116by deleting the user record652corresponding to the content item. Block854then directs the microprocessor200back to block832onFIG.8Aand the dashboard display process800is repeated. If at block850no request to delete content has been received, the microprocessor200is directed back to repeat the process starting at block832.

The content dashboard screen700thus provides a convenient listing702of content owned by the user116of the first networked device114, and facilitates easy access to the content. The content dashboard screen700further provides access to content uploading functions via the “upload” button722, privacy settings via the privacy controls716, and the ability to delete content via the “delete” buttons714.

Downloading Content Data

Referring toFIG.9A, a flowchart depicting blocks of code for directing the processor circuit300of the second networked device118to initiate a content access request is shown generally at900. A flowchart depicting blocks of code for directing the server processor circuit104to handle the access request is shown generally at920. The processes900and920are described in the context of the user120of the second networked device118requesting access to the content item uploaded by the user116of the first networked device114in accordance with the device upload process400shown inFIGS.4A and4B. The content access request process900implemented by the second networked device118starts at block902when a user120of the second networked device118causes a content dashboard screen740shown as a screenshot inFIG.7Bto be displayed. The content dashboard screen740is similar to the content dashboard screen700for the user120of the first networked device114, with the exception of a listing744that includes different content items and the different user name “John Smith” associated with the user120of second networked device118. The content dashboard screen740includes a first tab750(“My files”) and a second tab752(“shared with me”), but in this example the second tab is activated and thus a listing744includes files that have been shared by other users with the user120.

The content access request process900continues at block904, which directs the microprocessor302determine whether an “Access Content” button742on the screen740has been activated by the user120. If the Access Content” button742has been activated, block904directs the microprocessor302to change the content dashboard screen740to include an access key entry box746and an access key request button748. In this example, the user120of the second networked device118enters the access key “Yerevan”, which is associated with the content uploaded by the user116in accordance with the device upload process400. Block904then directs the microprocessor302to determine whether an access request has been initiated by the user120entering an access key in the access key entry box746and activating the access key request button748. Until the button748is activated, block904directs the microprocessor302to repeat block904. When the access key request button748is activated, block904directs the microprocessor302to block906, which directs the microprocessor to transmit a content access request including a request access key to the server102using a TCP connection established with the server102over the data network108. The content access request process900then continues at block908, which directs the microprocessor302to await receipt of updated content dashboard data from the server.

The access request handling process920begins at block922, which directs the microprocessor200of the server102to determine whether a content access request has been received from a networked device, such as the second networked device118. When the content access request transmitted by the second networked device118at block906is received, the microprocessor200is directed to block924. Block924directs the microprocessor200to process the content access request to extract the request access key (in this case the characters making up the alphanumeric access key “Yerevan”). Block926then directs the microprocessor200to perform a database query of the access key table630in the networked database112. The process920then continues at block928, which directs the microprocessor200to determine whether the query performed on the access key table630at block926returned a result. If no access key matching the request access key is found in the access key table630, it may be that the user120of the second networked device118had incorrectly entered the access key. If at block928, the microprocessor200determines that there is an access key in the access key record632that matches the request access key, block928further directs the microprocessor200to read the expiry field646in the record632and to determine whether the access key has expired. If at block928, the request access key does not match any records in the access key table630or the access key is found in the access key table but has expired, block928directs the microprocessor200to block930. Block930directs the microprocessor200to transmit a status message to the second networked device118indicating that the access key that was entered is not associated with any content data stored in the storage location110. In one embodiment the status message when received at block908, causes the microprocessor302to display the status message on the second networked device118as a pop-up box (not shown) on the content dashboard screen740.

In the example shown inFIG.7Bwhere the request access key is “Yerevan”, this access key appears in the access key field642of the access key record632inFIG.6B, and is thus determined to exist. Further, if the microprocessor200determines that the expiry field646holds a later time and date value than the current time and date, the access key “Yerevan” is determined to remain actively associated with content data stored in the storage location110.

The process920then continues at block932, which directs the microprocessor200to read the content_id field644of the access key record632in the access key table630. Block934then directs the microprocessor200to query the metadata table600using the value in the content_id field644to select the an applicable metadata record602in the metadata table600(i.e. record602in this example).

Public Content Download

Block936then directs the microprocessor200to determine whether the public_private field622in the metadata record602is set to “public”, in which case the microprocessor is directed to block938. Block938directs the microprocessor200add a new record666to the user table660for the user120of the second networked device118(shown inFIG.6D). The new record666includes the content_id field668set to the access key “HyKiJyOcm” and the status field670set to “shared”, indicating that the user120is not the owner of the content referenced in the content_id field. Block938then directs the microprocessor200back to block840of the server dashboard update process830shown inFIG.8Afor updating the content dashboard screen740on the display304of the second networked device118. Blocks840and842cause updated content dashboard data to be transmitted to the second networked device118.

The content access request process900resumes at block908when updated content dashboard data or a status message transmitted at block930is received. When the content dashboard data is received the microprocessor302is directed to block806of the dashboard display process800shown inFIG.8Afor updating the content dashboard screen740.

Private Content Download

If at block936, the microprocessor200determines that the public_private field622is not set to “public”, then the public_private filed is set to “private” and the microprocessor is directed to block940(shown inFIG.9B). In the example described herein the content data associated with the access key “Yerevan” has been designated by the user116of the first networked device114as “private” content. Block940directs the microprocessor200to query the metadata table600for the content_id read at block932and to read the owner field616in the metadata table to determine the owner of the content (in this case Tom Stevens). Block940also directs the microprocessor200to generate a notification_id. In one embodiment the notification_id may be an alphanumeric string having 9 characters, which is randomly generated and uniquely associated with the notification record682.

The access request handling process920then continues at block942, which directs the microprocessor200of the server102to write a new record to a notifications table, shown inFIG.6Eat680. In the example shown, a single notification record682includes a notification_id field684, a content_id field686, an owner field688, and a requestor field690. The notification ID field684in this embodiment is set to “hj7Ytksf6” and the content_id field686to “HyKiJyOcm”, which corresponds to the content referenced by the access key “Yerevan” in the metadata record602. While only a single notification record682is shown in the notifications table680, the table will typically include several notification records for content owned by different users. Block942may further direct the microprocessor200to transmit a confirmation message to the second networked device118. The confirmation message confirms for the user120that access to the private content identified by the request access key has been requested. The confirmation message may be displayed as a pop-up box (not shown) displayed over the content dashboard screen740on the second networked device118.

The process then continues at block944, which directs the microprocessor200to determine whether the server102already has WebSocket connection open with the owner of the private content identified by the request access key (i.e. the first networked device114). If at block944a WebSocket connection is open this indicates that the owner of the content data being requested is currently using the content sharing application and block952directs the microprocessor to block946. Block946directs the microprocessor200to look up the metadata record602in the metadata table600and to generate a notification message. In one embodiment the notification message includes an identification of the content data being requested by including information from the metadata record602such as any or all of the file_title field624, the file_description field626, data type field620, and the data size field618. The notification message also includes the name of the requestor (i.e. the name of the user120of the second networked device118). Block948then directs the microprocessor200to transmit the notification message to the first networked device using the open WebSocket connection. The notification may be displayed as a pop-up on a screen currently displayed on the display304of the first networked device114and may additionally include buttons to grant or deny access to the content data. Block948of the server process920then directs the microprocessor200to initiate a notification handling process shown at950inFIG.9C. Block950then directs the microprocessor200back to block922to await further download requests.

Referring toFIG.9C, the notification handling process950is implemented on the server102for handling a notification response from the first networked device114. Block952directs the microprocessor to determine whether a response has been received from the first networked device114. If no response is received at block952, the microprocessor200is directed to block954, which directs the microprocessor to determine whether a timeout period associated with the request has expired. If the timeout has not yet expired, block954directs the microprocessor200back to block952, which is repeated. If at block952, a response is received from the first networked device114, the microprocessor200is directed to block956. Block956directs the microprocessor200to determine whether access to the data content for the user120has been granted by the user116of the first networked device114. If access has been granted, block956directs the microprocessor200to block958, which directs the microprocessor to write the content_id to the user table660for the user120(John Smith) shown inFIG.6D. Referring back toFIG.6D, the record666has been written to with a content_id field672set to “HyKiJyOcm” and a status field674set to “shared”. Block958thus has the effect of causing the content data item to be added to the content that is accessible by the user120. When the second networked device118next updates their content dashboard screen shown inFIG.7Bat740, the content data item754will be displayed in the content listing744as shown at754.

If at block954the timeout period expires, or at block958the response from the user116of the first networked device114declines to grant access to the data content, then the microprocessor200is directed to block960and the notification record682corresponding to the content-id “HyKiJyOcm” is deleted from the notifications table680.

If at block944of the access request handling process920, no WebSocket connection is open for the first networked device114, the microprocessor200of the server102is directed back to block922to await and process further content requests. In this embodiment, when the user116of the second networked device118is not currently connected to the server via a WebSocket connection, the notification is deferred until a time that the user logs in to the application again.

Referring toFIG.9D, a process implemented on the server102for transmitting deferred notification requests to a user such as the user116of the first networked device114is shown generally at980. The process980is executed whenever a user of a networked device launches the application and logs in. The process980is described in the context of generating a notification for transmission to the user116of the first networked device114indicating that the user120of the second networked device118has requested access to content data owned by the user of first networked device. The server deferred notification process980begins at block982, when the user116of the first networked device114launches the application and logs in via the screen500shown inFIG.5A, as described above. Block982then directs the microprocessor200to query the notifications table680for any records having an owner field688matching the name of the user (in this case the user116“Tom Stevens”).

The process980then continues at block984, which directs the microprocessor200to determine whether any matching notification records exist. If a matching notification record exists (such as the record682) the process continues at block986. Block986directs the microprocessor200to read the content_id field686in the notifications table680and to look up metadata corresponding to the content_id in the metadata table600(i.e. the metadata record602in this case). Block986also directs the microprocessor to generate a notification message generally as described above in connection with block946. In this case the name of the requestor is read from the requestor field690in the notifications table680for inclusion in the notification message. Block948then directs the microprocessor200to transmit the notification message to the first networked device using the open WebSocket connection for the first networked device114. Block948also directs the microprocessor200to initiate a notification handling process950, shown inFIG.9Cand directs the microprocessor200back to block922to await further download requests.

Referring toFIG.9E, a process implemented on the second networked device118for requesting a download of a content data item listed in the listing744of the content dashboard screen740is shown generally at980. A process implemented on the server for handling the request to download the content data item is shown generally at990. The networked device process980begins at block982, when the user120of the second networked device118selects one of the content data items in the listing744. If at block982a content data item is selected from the content listing744, the microprocessor302is directed to block984. If no item is selected at block982, the microprocessor302is directed back to repeat block982. Block984directs the microprocessor302to generate and transmit a request to the server102to download the content associated with the selected data content item. In the discussion following it will be assumed that the content data item754has been selected for download by the user120of the second networked device118. The request to download the content associated with the selected data content item would need to include an identification of the content, such as for example the Name “Image.jpg” and size “2.031” to permit the server102to identify the content being requested.

The process990begins at block992, which directs the microprocessor200of the server102to determine whether a download request has been received from the second networked device118. If a request has been received, block992directs the microprocessor200to block994. Block994directs the microprocessor to look up the content record by content_id in the metadata table600(i.e. in this example the metadata record602) and to read the address field614in the record. Block994then directs the microprocessor200to download the data content from the storage location110at the address held in the address field614. Block996then directs the microprocessor200to transmit the content data to the second networked device118as a download stream. Block998then directs the microprocessor200to monitor the progress of the download, and when completed block998directs the microprocessor back to block992to await further download requests.

The networked device process980continues at block986which directs the microprocessor302of the second networked device118to determine whether the download is completed. When completed, block986directs the microprocessor to block988, which directs the microprocessor302to call an operating system function in the block of program codes220of the program memory202(FIG.2) to cause the downloaded data to be displayed. For example, where the data content is an image, an operating system function that causes images to be displayed may be invoked so that the image is displayed on the display304of the second networked device118.

Access Key Assignment

While the above embodiments have been described with reference to an alphanumeric access key selected by the server102other types of access key may also be handled by the server. For example, while block436of the server upload process420causes the server102to assign an alphanumeric access key, this block may be replaced by a process that permits other options for selection of the access key by the user uploading content data. Referring toFIG.10, a process implemented on the server for assigning an access key is shown generally at1000. The process1000may replace block436in the server upload process420and begins at block1002. Block1002directs the microprocessor200to determine whether a text access key has been received from the first networked device114. If no access key has been received at block1002as part of the content data upload, the microprocessor200is directed back to block436of the server upload process420and an access key is selected from the database as described above.

In this embodiment the user116of the first networked device114may submit an access key when the content data upload is initiated at block408of the device upload process400inFIG.4A. If an access key has been received at block1002, the microprocessor200is directed to block1004, which directs the microprocessor to determine whether the access key consists of alphanumeric characters. If the access key is alphanumeric, block1004directs the microprocessor200to block1006. Block1006directs the microprocessor200to write the access key to a new record in the access key table630with the access_key field set to the received alphanumeric access key and the content_id set to the value generated at block434of the server upload process420. Block1006also directs the microprocessor200to set the access key expiry, as described above in connection with block436. The microprocessor200is then directed to block438of the server upload process420, and the process continues as described above.

In one embodiment, the ability to select an alphanumeric access key rather than have one assigned by the server102may be linked to the level of membership of the user. For example, only paid members may be offered this option or a minimum number of characters in the keyword may be restricted for unpaid members. Paid members may be permitted to use short keywords, while unpaid members may be required to provide some pre-determined minimum number of characters. In another embodiment, the access key may be contained within a Quick Response Code (QR code), barcode, or other encoded pattern displayed on a product or in connection with a service. In this case the user116of the first networked device114when uploading data content would provide an alphanumeric character string that corresponds to the alphanumeric characters encoded within the pattern when uploading data. The user120of the second networked device118, when requesting the data content would then use the camera340to capture the encoded pattern and cause the microprocessor302of the processor circuit300to extract the alphanumeric character string that would form the basis of the content access request.

If at block1004, the access key is not alphanumeric, the microprocessor200is directed to block1008. Block1008directs the microprocessor200to determine whether an access key image has been received. If no access key image has been received, the user116of the second networked device118has failed to upload a valid access key and the process100continues at block1010where the microprocessor200is directed to transmit a failure message to the first networked device. If at block1008, an access key image has been received, the microprocessor200is directed to block1012. Block1012directs the microprocessor200to process the access key image. In some embodiments, the image file may be processed using a hash function to map the larger image data file to a smaller size hash value, which is stored in the access key field642. The hash function would be configured to generate hash values that have relatively low possibility of two different images yielding the same hash value. In some embodiments the access key image file may be an image uploaded by the user116of the first networked device114for use as the access key, or may be a portion of an image extracted from the content data by the server102. For example if the content is a set of presentation slide images, the server may extract one or more portions of the slides and use these as the access key.

Once the access key image has been processed at block1012, the microprocessor200is directed to block1014. Block1014directs the microprocessor200to write the processed access key image to the access_key field of a new record in the access key table630along with the content_id generated at block434of the server upload process420. Block1006also directs the microprocessor200to set the access key expiry, as described above in connection with block436. Block1014then directs the microprocessor200back to block438of the server upload process420and the remaining blocks of this process are completed as described above.

Request Access Key Handling

At block924of the access request handling process920the server102is directed to process the access request to extract the access key. For a simple alphanumeric access key, this would involve opening up the content access request and reading the characters from an access key string. Referring toFIG.11, a process for implementing block924of the process920to accommodate additional content access request options is shown at1100. The process begins at block1102, which directs the microprocessor200to read the content access request received at block922of the process920to extract the access key. In this embodiment the access key may be an alphanumeric character string, an image file captured by the camera340of the second networked device118, or an audio file representing words spoken by the user120of the second networked device captured by the microphone334and encoded within an audio file by the audio processor332.

Block1104then directs the microprocessor200to determine whether the request access key is alphanumeric, in which case the microprocessor is directed back to block926of the process920. If the request access key is not alphanumeric, block1104directs the microprocessor200to block1106. Block1106directs the microprocessor200to determine whether the request access key is an audio file, in which case the microprocessor is directed to block1108. Block1108directs the microprocessor200to invoke the block of codes224for directing the microprocessor to provide speech recognition functions and to attempt to extract text associated with the spoken words in the audio file. Block1108then directs the microprocessor200back to block926of the process920, where the extracted characters are processed as described above for an alphanumeric access key.

If at block1106, the request access key is not an audio file, the microprocessor200is directed to block1110. Block1110directs the microprocessor200to determine whether the request access key is an image file. If the request access key is not an image file, then the user120has submitted an invalid request access key and the microprocessor200is directed to block1112, where a failure message is transmitted to the networked device. If at block1110, the request access key is an image file, the microprocessor200is directed to block1114, which directs the microprocessor to process the access key image. The processing of the access key image may be similar to the processing described above in connection with block1012of the process1000, including in some embodiments parsing the access key image to a hash function to extract a hash value. The process1100then continues at block1116, which directs the microprocessor200to compare the processed access key to the access key values in the access key table630in the networked database112. Block1118then directs the microprocessor200to determine whether an access key match is found between the processed request access key and one of the access key values in the access key table630. If a match is found, block1118also directs the microprocessor to determine whether the access key is remains unexpired and associated with content data. Block1118then directs the microprocessor200back to block932of the process920and processing continues as described above. If at block1118no access key match is found, the microprocessor200is directed to block1112, where a failure message is transmitted to the second networked device118.

The above disclosed embodiments enable sharing of content data, disclosed examples of which include jpeg image files and Portable Document Format (PDF) document files. Generally the disclosed processes will work with almost any other type of content, including other image file types such as Graphics Interchange Format (GIF), Tagged Image File Format (TIFF), bitmaps, etc. The content data may be contained in any of a plurality of different video file formats such as Audio Video Interleaved (AVI) format, MPEG video formats, Windows Media Video (WMV), or other video file formats. Most networked devices have the ability to open and display content in a variety of document, image, and video formats. The content data may alternatively have been generated within a software application such as a word processor, spreadsheet program, a presentation program such as Microsoft PowerPoint, a Computer-aided design (CAD) program, or any other program that produces content data in either a proprietary or open format. In this case the recipient networked device would need to have installed the application program or a viewer to be able to view the content.

The embodiments for sharing content data disclosed above may be used in a variety of different applications. A file sharing application has been described in some detail above and facilitates rapid and convenient sharing of content data files between individual users. Many other file sharing applications or platforms require that an email or text message be sent from the user making the content available to the recipient user. The email or text message generally includes a full address that identifies the exact location of the content on the network. The address is typically a long alphanumeric string, mostly in the form of a clickable reference link activated by clicking or tapping on the link. The above disclosed embodiments eliminate the need to exchange the full address of the content in favor of a very much shorter alphanumeric access keyword, which may be a meaningful word that can be easily remembered. Alternatively, the access key may be included within an image that facilitates easy extraction and association with the content data. The above disclosed embodiments also eliminate the need for the uploading user and recipient user to have each other's contact details in order for the content data sharing to be effected. Typically when individuals wish to share content on an ad-hoc basis without posting the content on a website or other media platform, contact details of the recipient user such as an email address or telephone number are required in order to send the content address or link to the recipient. The above disclosed embodiments permit a user to share publically available content data without even knowing the recipient user.

The above disclosed embodiments also have application in the automobile trade. A flowchart for an automobile vending process implemented using the various processes disclosed above is shown generally inFIG.12. Referring toFIG.12, steps performed by the automobile vendor are shown at1200. The process begins when the uploading user (i.e. the automobile vendor) launches the content sharing application by executing the device upload process400shown inFIG.4A. The process then continues as shown at1204, where the automobile vendor uploads content associated with the automobile that is for sale by executing a remaining portion of the device upload process400shown inFIG.4B. The automobile vendor may upload content such as images, brochures, specifications, road report, or any of a variety of different types of content associated with the automobile for sale that would be of interest to a purchaser. At1206, the automobile vendor may update the metadata associated with the uploaded content and also designate the content as either private or public. As shown at1208, the processing differs depending on whether the content is public or not. If the content is designated to be public which is the most likely option, the automobile vendor may optionally take additional steps to publicize the content by making the access key available. For example, the automobile vendor may provide notice to the public that content data for automobiles on a vendor lot are accessible via the vehicle registration plate number. In some cases where the automobile vendor wishes to make the content private, the automobile vendor would continue to monitor requests for access as shown at1210.

Steps performed by a potential purchaser are shown at1220. The process begins when the recipient user (i.e. the potential purchaser) launches the content sharing application. As shown at1224, the user then provides an access key generally as described above in connection with the process900inFIG.9A. In some cases the access key may be entered by capturing an image of the vehicle registration plate or other identifying information such as the VIN plate. In other cases the access key may be manually entered as a plate number or other keyword as advertised by the automobile vendor. If the content is public, as shown at1226, then the content will be made directly available as shown at1228by adding the content to the user's dashboard as described in connection with block908inFIG.9A. If the content is private, the user would need to monitor the dashboard as shown at1230to determine whether an access notification has been received (described in connection with the process950inFIG.9C). Once access is granted, the user may access the content as shown at1228.

The automobile vendor application may be used by new or used automobile vendors to share content applicable to a specific automobile with potential purchasers. Usage is not limited to vehicles on an automobile vendors lot, but could also extend to automobiles in active use on the roads. Additionally, whenever access to content data for an automobile is requested, a notification including the requesting user's contact information may be sent to the automobile vendor. The application is thus capable of establishing a communication channel between automobile vendor and potential purchasers.

In another commercial application, a vendor of any product or service may make use of the above disclosed embodiments to share advertising content with interested users. Referring toFIG.13, an example of an advertisement that may be carried in a magazine, billboard, newspaper or any other advertising medium is shown at1300. The advertisement1300may be displayed in print form or electronic form depending on the nature of the advertising campaign. The advertisement1300includes an access keyword “Milk”1302in conjunction with the “LinkMe” label1304. In other embodiments the label1304may be replaced by a recognizable logo that designates the access keyword1302as being associated with the content sharing application described herein. The vendor placing the advertisement will have previously uploaded content data as described in the device upload process400inFIG.4. The content data may provide additional information about the product, for example Nutritional information, product information, etc. An interested recipient user would launch the content sharing application and either manually enter the access keyword “Milk” or capture and submit an image of a portion of the advertisement1300including the access keyword1302to access the content generally as described in connection with the process1220inFIG.12.

As an alternative to the access keyword1302and label1304, the advertisement1300also includes a telephone number1306. Since telephone numbers are unique to the subscriber, the telephone number1306provides a convenient access key for accessing content data. As described above, the recipient user may enter the telephone number1306manually or capture and submit an image of this portion of the advertisement1300. In other embodiments the access key may be a registered business name that has been registered with the content sharing application provider as a permanent or subscribed access key.

In another embodiment, vendors of professional and other services may upload content data such as a professional profile, resume, or information about offered services. The content data may be associated with a company name, telephone number or other designated access key on the professional's business card. Subsequently a recipient of the professional's business card may conveniently access more information about the services offered. Similarly, a professional making a presentation at a conference or networking event may upload materials or a copy of the presentation for access via an access key such as an image of a portion of the presentation file displayed during the presentation, a keyword displayed during the presentation, or an access keyword included in materials related to the presentation. The recipient user is thus provided with convenient access to the uploaded materials without contacting the presenter.

While specific embodiments have been described and illustrated, such embodiments should be considered illustrative only and not as limiting the disclosed embodiments as construed in accordance with the accompanying claims.