Blockchain Fintech – Jeffrey McGregor, Craig Stack, Jason Lyons, Matthew Robben, Truepic Inc
Abstract for “Proof of Image Authentication on a Blockchain”
“Disclosed is an improved technology to authenticate electronic images and store proof of tampering/non-tampering on blockchain. A user device’s image authentication application may produce an image. A hash function may be used to generate an image hash from the device. The image hash can be written to the Blockchain. This can happen immediately after an image is taken. An authentication server may be used to authenticate the image. The authentication server can generate an image hash using the hash function at various times such as after receipt, authentication and/or authentication. The image hash(es), which may be generated by the authentication server, may be written to the blockchain. To determine if the image has been altered between different times, the blockchain may record the state of the image at different times.
Background for “Proof of Image Authentication on a Blockchain”
Since its inception, digital photography has seen steady growth. The growth in photographic data available to the public has been further accelerated by social networks and mobile computing devices. Because it is easy to share and take photos anywhere and anytime, the public has become more dependent on these photos for the most up-to-the minute information. It is well-known that digital photos can be easily edited, and therefore the information in a digital photo may not always be trustworthy. Digital photographs and electronic images can be used to create trustworthy evidence (also known as “images”). It can be difficult to obtain trustworthy evidence based on digital photographs and other electronic images (also referred to herein interchangeably as?images?). This is because technology can alter or compromise the integrity of these images. These problems and others are present with traditional image collection systems and authentication systems.
“Authenticated photos are useful in many cases, especially when the photo is used to prove or support a fact or set facts. Many industries face technical issues related to remote inspections and virtual underwriting. A trusted inspector needed to visit a business, property or asset in person to conduct an inspection. This can be costly and time-consuming.
“The technology allows remote inspections. This technical solution has created other problems. There are many technologies that allow images, location data and metadata to be altered easily. This is a common problem with images (photos and video) being used to facilitate remote inspection.
“One example of this is when it comes to insurance claims. There are many applications and technologies that allow an unscrupulous user in the context to metadata manipulation, location-spoofing, photo manipulation, taking photos of other photos, and using images from the Internet that purports to be images that the user captured. These technical issues can have a negative impact on the integrity of claims or underwriting.
These and other technical issues exist in many industries, in many contexts in which image data is submitted instead of an in-person physical examination.
“The invention is a technical solution that addresses these and other issues in relation to the use of technology to authenticate electronic images and provide proof that they have not been altered.”
The authentication server might authenticate one or more images. This authentication could include, among others, performing a reverse search of each one or more electronic image using an image platform. To determine if a match is found, the electronic images can be compared against a list of electronic images. This may involve creating a hash from the image and/or using an image authentication app executing on the user device. The hash can then be searched and compared against each image in the electronic image database. The hashes might match, indicating that the uploaded electronic image is not authentic. The image could, for example, be an image already taken by the image authentication app or copied from an internet search and uploaded (assuming that it was tampered with).
“Other methods may also be used for authentication. The image authentication application might transmit metadata to the authentication servers that can be used to authenticate. The metadata can include information about the time and/or location of images that can be used for authentication. The metadata could include information such as the time and/or place at which the image authentication software was downloaded, installed and opened. It can also contain images that were generated and uploaded. This information may be used to determine how long it took or how far distance was traveled between events of interest. The picture might not be authenticated if it takes longer than the predetermined time period from the application installation to the taking of the picture. This could be because the user had the time to compromise the image and/or application. Sometimes, the location of the user based on metadata can be compared with an expected location (e.g., a home or work address) which could be provided by the requesting entity, such as the insurance company. The picture may not be authenticated if the distance between the expected location and the user’s location is greater than a predetermined distance.
The authentication server can provide one or more electronic photos, any associated metadata and indication of authentication (or failed authentication, reason for failure), the unique identifier and/or additional information through the portal UI. The requesting device can then obtain one or more electronic photos, which may be authenticated.
“In some instances, the various processes described herein could generate a transaction that can be transmitted to a Blockchain network. The transaction could be written as a block on the decentralized ledger. The image authentication application might generate and transmit transactions each time an image is taken, uploaded or at any other time. An authentication server might generate and transmit transactions each time an image is received, authenticated, or at other times. A hash of the image generated by the image authentication app may be included in the transaction’s payload. The decentralized ledger may contain an immutable record of each image at different stages. The decentralized ledger may contain the hash of the image at each stage of the process: upload, generation, authentication and/or any other. These can be compared to ensure that the images are not altered.
“In some cases, an image authentication application on the user device might generate an image for authentication. The image authentication application might generate an image hash using a hash function such as a one way hash function. The authentication server may receive the image from the image authentication app. The image hash may be written to the blockchain by the user device. A record of the image hash can be made on the blockchain. This records the state of an image after it is generated by an image authentication app and before it is transmitted to an authentication server.
“In some cases, after receiving the image, an authentication server may generate an image haveh using the hashing functions (e.g. the same hashing algorithm used by the image authentication app). The image hash generated by the authentication server can be written to the blockchain. A record of the image hash can be made on the blockchain. This records the state of each image once it has been received. You can generate image hashes during authentication, and then write the hashes to your blockchain. A record of the image hashes may be kept on the blockchain. This records the state of an image at different times during and/or following authentication. To prove that an image is not altered or altered between different points in time, the hashes of the image stored on the blockchain may be retrieved. The image hashes can be compared to prove that the image was not altered from the moment it was created to the time it is uploaded to the server.
“While the examples above and others may have been used to illustrate an insurer asking for authenticated images from its insureds, the system can be used in many other situations in which an entity wants to obtain images from users to verify their authenticity.”
These and other features and characteristics of the system/method disclosed herein, along with the methods of operation, functions, and combinations of parts and economies, will be more obvious if you read the following description and refer to the attached claims. All of these forms a part this specification. In which like reference numbers designate the corresponding parts of the various figures, The drawings should be understood that they are intended to illustrate and describe the invention and not as a limitation of its capabilities. The singular forms of?a,?an, and??the are used in the specification as well as in the claims. If the context requires otherwise, include plural referents
According to one aspect, a variety of disclosed systems and methods can authenticate images based upon requests from entities to obtain authenticated electronic images from users. An entity could include an insurance provider, which requests that its insured upload images related to an insurance claim. These images might be images documenting damage to a vehicle. In order to reduce fraudulent claims, the system can provide a special application that can be installed on a user’s device. The insurance provider might request images from its insured and send it to the authentication server. An electronic address may be included in the request. An authentication server might provide a link to the electronic adress. The link could include a network address from which you can download the application, as well as a unique identifier that is associated with your request. After the insured selects the link, the insured’s user device can download the application. This application is separate from native camera applications and may generate one or several images. The images can be transmitted to an authentication server along with their unique identifier to prevent tampering. An authentication server can authenticate an image by comparing it with a list of images. The authentication server might perform a reverse image search of the image. The authentication server can also authenticate the image using alternative or additional methods. The unique identifier was used to identify the images. The authentication server can provide images and metadata, as well as authentication results, to the insurer.
“FIG. “FIG. 1” illustrates a system 100 for authenticating electronic images according to an implementation. System 100 could include an authentication server 110 and one or more user devices 120. A linking system 130, an imaging platform 140, an application store 150, a network 1 consisting of multiple nodes 10, a distributed ledger 2 made up of multiple blocks 3 and/or other components. System 100 components may communicate with each other via a network 101.
“Refer to FIG. 2. This diagram illustrates a data flow 200 for authenticating electronic images according to an implementation. An interface portal (?UP?) may be generated by the authentication server 110. The authentication server 110 may generate a portal user interface (?UP?) through which the requesting devices 108 can request authenticated images from the authentication server 120. One or more input options may be provided by the portal UI 211 to allow the user to specify the request parameters for authenticated and secure images. The portal UI 211 can receive, for example, a name and an email address of a user at operation 201. It may also receive a client-generated identifier, such as an insurance claim number, an expected location of a user (e.g. a home or office address), a note and/or any other information necessary to request the authenticated images.
“At operation 202, portal UI 211 might receive the request parameters. They may then forward them to authentication server 110.”
“At operation 204, an authentication server 110 might generate one or more links parameters and send them to the linking network 130 to create a link to the user’s electronic address. Link parameters can include an electronic address from which you can download the image authentication application 101, an unique identifier and/or any other information. The link parameters can be based on any one or several of the request parameters in some cases. The client-generated identifier could be included in the unique identifier. To track the request, the authentication server 110 may generate the unique identifier. Each image authentication application 101 can be customized to suit the needs of each entity. The image authentication 101 might be white-labeled to each requester entity, for example. These implementations may allow the authentication server 110 to identify the requesting entity and to identify the appropriate image authentication 101 (such as one that was white-labeled to the requesting entities) that will be sent to the user’s electronic address. Other implementations may contain a single application in the image authentication 101. The unique identifier may allow the single application to customize its content (including appearance and feel). Each unique identifier can be associated with a corresponding entity. This allows the application to create custom content based upon the identity of the entity.
“At operation 206, the linking software 130 may create a link using the link parameters.” The link could encode the electronic address from which the image authentication application 101 can be downloaded and the unique identification.
“At operation 208, authentication server 110 may transmit a link to the electronic adress. The authentication server 110 might generate a message with the link and send it via the appropriate communication channel. The authentication server 110 can transmit the message via a Short Message Services (?SMS) if the electronic address is a mobile number. Multimedia Messaging Service, (?MMS?) Text message. The authentication server 110 can transmit the message electronically if the electronic address is an email address. Depending on the type of electronic address, other types of electronic communication can be used to send the message.
“At operation 210, user device 120 might receive the link to download the image authentication app 101 from the app store 150. An app store 150 could include an app store from a third party such as APPLE APP SHOP STORE or GOOGLE PLAY. An internal app store may be included in the app store 150 provided by authentication server 110.
“If the electronic address refers to a mobile number, the user device 120 could include a mobile telephone that displays the message as a text message. The message might invite the user to interact with the link to download image authentication software 101.
“At operation 212, app store 150 may identify an image authentication application 101 based upon the link and transmit it to the user’s device 120. The app store 150 might store multiple image authentication apps 101 that are white-labeled to a particular entity. The user device 120 can download and install. All of the above may be done automatically, without user intervention. The user device 120 might open the image authentication app 101 automatically in some cases. In other instances, it may respond to user input (such as selecting the icon that corresponds to the application). The unique identifier encoded within the link may be included in the image authentication app 101. The image authentication application 101 might store the unique ID in hidden fields that are used to submit the authentication server 110. There are other ways to store and send the unique identifier. The image authentication app 101 may store the unique ID without the need for user intervention at the device 120. These implementations may not require the user to register in order to use the image authentication app 101. After downloading and installing, the image authentication software 101 may be used for one or more electronic images to be authenticated.
“An operation 214 allows the user device 120 to generate and transmit one or more electronic images along with related data (such a hash of an image, metadata, EXIF, or similar data) at the authentication server 110.
“At operation 216, authentication server 110 might authenticate one or more images. This authentication could include, among others, performing a reverse search of each one or more electronic images via image platform 140. To determine if a match is found, the electronic images can be matched against an electronic image database 140. This may involve creating a hash from the image and/or using the image authentication app 101 executed at user device 120 to search for it. The hash is then compared against each image in the electronic image database. The match between the hashes could indicate that the uploaded electronic image from user device 120 is an existing one, which may mean that the image is not authentic. The image could, for example, be an image already taken by the image authentication app 101 or copied from an internet search and uploaded (assuming that it was tampered with).
The image authentication server 110 might obtain the results of the reverse-image search from the image platform 140 at an operation 218, Other authentication methods may also be used, including comparing metadata that indicates the location where the image is generated with the expected location (e.g. comparing the time at the which image authentication 101 was downloaded with the time at the which the images were taken or uploaded. Likewise, comparing the time at the which image authentication 101 was downloaded with the time when an image of that location was taken and the location where it was uploaded. Using other validation techniques, you might compare the location in which image authentication 101 was opened with the location at the which image was created. These time and/or geographical requirements ensure that the user does not have enough time to modify the image file.
“At operation 220, authentication server 110 can provide one or more electronic pictures, any associated metadata and indication of authentication (or failed authentication, reason for failure), the unique identifier and/or additional information through the portal UI 201. The requesting device 208 can obtain one or more digital images that have been authenticated. Even though the information is not illustrated, it may be written to decentralized ledger 2, for immutable storage or authentication.
“Referring to FIG. The blockchain network 1 could be made up of multiple nodes 10. Minimum one of the nodes might include its own copy the decentralized ledger. Multiple blocks may make up the decentralized ledger 2. Each block refers to a previous block’s hash. A variety of processes described herein may result in a transaction that is transmitted to the blockchain network 1. (e.g. to one or more peer-to-peer communication protocols). The transaction can be written to block 3 of the decentralized ledger. The image authentication application 101, for example, may generate and transmit transactions each time an image has been taken, uploaded, or at any other time. An authentication server 110 could generate and transmit transactions each time an image is received, authenticated and/or at another time. A hash of the image created at image authentication application 101 may be part of the transaction’s payload. This will allow for an immutable record of each image during various processes or stages. To verify that an image is not altered during these processes, one can retrieve the hash of the image at upload, generation, authentication and/or other times from the decentralized ledger 2.
“FIG. “FIG. One or more processors 312, one, or more storage devices 314 and/or other components may be included in the authentication server 110. Instructions that program the processors may be stored on one or more of the storage devices 314 One or more storage devices 314, may contain instructions that program one or more physical processors 312.
“The interface portal 31 may create one or more interfaces to receive requests from users for authenticated images. The portal UI 211 may be generated by the interface portal 316. The interface portal 316 might implement multiple layers of authentication in some cases. The authentication server 110 might have registered clients previously to allow them to use the system to request authenticated photos from users. Clients may register one or several of their requesting devices (108 or network gateway). The system could store, for example, valid Internet Protocol (?IP?) addresses. The system may store valid Internet Protocol (?IP?) addresses that are associated with registered clients. The interface portal 316 can whitelist IP addresses to allow a requesting device’s IP address 108 to be compared with whitelisted IP addresses previously registered. You may also use other layers of authentication, such as secret key/password or other authentication mechanisms.
The portal UI 211 may have one or more input options that allow users to specify the request parameters for authenticated and secure images. One or more user input options can be used to request a user’s name (e.g. person or entity), an electronic address, a client-generated number (e.g. an insurance claim #), an expected location (e.g. a home address or work address), and a note about the user.
“In certain cases, the client-generated ID may be stored together with a user login used for authentication. An example is that an insurance provider might have multiple claim staff to handle insurance claims. This could be because the claim number, which may also serve as the client’s identifier, may be used by an entity like an insurance company. The portal UI 211 can display the insurance personnel with the claim numbers that they are handling upon login by claim personnel. The portal UI 211 may present the claim number and any relevant images or other information that was collected by the system.
“Responsive” to the request for authentication images, the link generator 318 might identify the entity that made the request. Based on the identity of the requester, the specific white-labeled photo authentication application 101 can be identified. The link generator 318 can encode the link using a download location for white-labeled photo authentication application 101 and a unique ID, which could be either a client-generated or system-generated identifier. The request parameters may include the client-generated or system-generated IDs. Sometimes, the link can be generated as bitly code, tinyURL or a combination of both. This URL may then be associated with a full URL that includes parameter inputs. In this case, the parameter input may contain the unique identifier. The link generator 318 will send a message with the link to the email address provided in the request for authenticated images. The message can include the following: the request, client-generated ID, unique identifier (if it is different from the client’s identifier), contact information and/or any other information. The link generator 318 can provide multiple messages related to each other in order to create a conversational atmosphere. For example, it may include a claim number and contact number in separate messages. The authentication server 110 can receive images from the image authentication app 101 after it is installed and executed on a user device 120.
The server-based image authentication app 320 can authenticate one or more images in a variety of ways. The server-based image authentication app 320 might authenticate one or more images through a reverse image search. Each of the electronic images can be matched against a list of electronic images in order to find a match. This may involve creating a hash from the image and/or using the image authentication app 101 executed at user device 120 to search for it. The hash is then compared against each image in the electronic image database. The match between the hashes could indicate that the uploaded electronic image from user device 120 is an existing one, which may mean that the image is not authentic. The image could, for example, be an image already taken by the image authentication app 101 or copied from an internet search and uploaded (assuming that it was tampered with).
Other authentication methods may also be used, such as comparing metadata that indicates a place at the which the photo was created with an expected location (e.g. comparing the time at the which the picture authentication app 101 was downloaded with the time at the which the images were taken or uploaded. Similarly, comparing the time at the which the file was downloaded with the time when the image upload was made to the authentication servers 110. Likewise, comparing the location where the image authentication software 101 was opened with the location where an image is being uploaded. These time and/or geographical requirements ensure that the user does not have enough time to modify the image file.
“These and other authentication technologies described in greater detail with regard to FIG. 4 and U.S. Patent Application Ser. No. No. Filled Aug. 3, 2015 (issued under U.S. Pat. No. No. 9.300,678 Mar. 29, 2016), and U.S. Patent Application Ser. No. No. 15/728.869 entitled?METHODS TO AUTHENTICATING PHOTOGRAPHIC IMAGE DATA? Filed on October 10, 2017, and the contents are hereby incorporated herein in their entirety.”
“The blockchain agent 322 might generate a transaction that can be transmitted to a Blockchain network. The transaction can be written to the decentralized ledger as a block. The blockchain agent 322 could generate and transmit transactions every time an image is taken, uploaded and/or at any other times (when the user device 120 is connected). When the authentication server 110 is used, the blockchain agent 322 can generate and transmit a transaction for each image received, authenticated and/or at any other time. A hash of the image generated by the image authentication app may be included in the transaction’s payload. The decentralized ledger may contain an immutable record of each image at different stages. The decentralized ledger may contain the hash of the image at each stage of the process: upload, generation, authentication and/or any other. These can be compared to ensure that the images are not altered.
“FIG. “FIG. The server-based image authentication app 320 may program some implementations so that the authentication server 110 can process some or all of the restrictions set by the user device 120. The authentication server 110 might receive information from the image authentication app 101 about time, location, and/or any other information that could be used to determine if the user had enough time to modify an image file. The image authentication app 101 may perform some or all the assessment described in FIG. 5 below. Authentication server 110 can then authenticate the image file in such cases, but only if such assessments indicate that the user did not have enough time to modify the file.
The authentication server 110 might use some of the geo-information (e.g. coordinates) received from user device 120 in different ways. The image authentication 101 might ask the user to identify the place where the photograph was taken. This information could be sent to the authentication server along with the application-recorded coordinate information. To verify that the information is accurate, the authentication server 110 can compare the recorded coordinate information to the address/points of interest information. Alternativly, the authentication server 110 can use coordinate information from the image authentication app 101 to search for the corresponding address or points of interest nearby and then suggest addresses/points that might be of interest to the user. Although the user has the option of including or removing geographic information from the authenticated image file, it is forbidden to modify or add unverifiable information.
“The authentication server 110 might create a resource locator identifier that is associated with authenticated image files and/or watermarked images so that third-party viewers can visit the URL to confirm that the image has indeed been authenticated. A web address, or a shorter web address, may be used to identify the resource location. This will direct third-party viewers to a website where they can view the authenticated and/or watermarked images. Third party viewers may upload a copy of the authenticated and/or watermarked image to the URL so they can compare the image they received with the authenticated one at the address. A third-party viewer might receive an image file that is allegedly authenticated by a user of the photographic authentication system. A watermark may be added to the image file to indicate that the photograph is authentic. It is possible, however, that the watermark was falsely applied to unauthenticated or edited images. The third-party viewer can visit the URL associated with the image to verify that it has been authenticated and not altered in any way. The web address can be included in the watermarked image (e.g., it may be part or all of the watermark), provided by the sender, or embedded in the image so that the user can click on the watermarked photo to go directly to the address. The web address can be either the complete address or a representation (e.g., a QR Code, tinyURL or bitly address) of the address. A third party viewer can check that the authenticated photograph is authenticated by visiting the URL.
“In some cases, authenticated metadata may be included by the authentication server 110. This includes server-applied date stamps, server-applied timestamps and geographical information. An authenticated file may also contain a resource location ID. This resource location identifier can be either a web URL or a representation thereof (e.g. bitly code or tinyURL or QR code). This scenario allows the authenticated file or a portion of the authenticated file to be uploaded to a website that is viewable by third parties. To show that the image has not been modified or revised, the user can share the authenticated file with third-party viewers. Third-party viewers can access the authenticated file and the URL to verify that the image was not altered or revised.
The authenticated file can contain any combination of authenticated images (i.e. the original image after it has been verified and verified by authentication server), authenticated metadata (e.g. authentication server-provided timestamps, datestamps and geographical data) and/or watermarked images. A watermarked image is the authenticated photo with a visual watermark attached to it to indicate that it has been validated by authentication server. Now, we will be focusing on the components of the above and other implementations.
“Having discussed various methods of determining whether a user had the time to modify an image file, and the results of authentication authentication, our attention now turns to authentication server components 120 that facilitate these functions and others. One or more physical processors 312, electronic storage devices 314, or other components may be part of authentication server 110.
“In an implementation, one or more physical processors 312 may be programmed using computer program instructions such as those stored on the one or multiple electronic storage devices 504. One or more of the physical processors 312 could be programmed, for example, by a server-based application 320.
“The server-based image authentication app 320 may contain various instructions, including a hash generator 412, network connection analyzer 414 and/or authentication engine 416. The various instructions are used herein to describe an operation. However, they actually program the physical processors 312 and authentication server 110 to perform the operation.
“In an implementation hash generator 412 is identical to hash generator 526 used in the image authentication app 101 illustrated in FIG. 5. This allows for a hash file to be generated at both the authentication server 110 or the user device 120. Examples of hash functions that can be used by the hash file generator 412 include SHA256 and SHA512. A database may contain multiple versions of different hash file generators in some implementations. A database can be used to retrieve the appropriate version of a hash generator if different versions are being used on different user devices 120. These implementations may allow user device 120 to communicate information that identifies the hash file generator type or version used. This information could be an image authentication app version, an identifier of the hash generator and/or any other identifying information used to identify authentication server 110 in order to retrieve the correct hash generator.
“In an implementation, the network connection analyser 414 can participate in network connectivity analysis and/or perform functions of the 528 network connection analyzer used by the image authentication app 101 illustrated in FIG. 5. This allows the authentication server 110 or the user device 120 to assess the quality and reliability of the network connection through which the authentication servers 110 and 120 communicate.”
“In an implementation, authentication engine 416 facilitates authentication image files captured at user device 120, even though use of a network connection for image files from user devices 120 to authentication server 110 should be limited (e.g. to minimize cellular data and/or when there is no network connection). The authentication engine 416 might receive an image file hash file from user device 120. The hash file is typically smaller than the image file so it can be sent over a cellular network or “poor” internet connection. The connection may be more efficient if it is of high quality (as discussed herein).
“FIG. “FIG. The user device 120 can provide various conventional messaging interfaces (not shown), such as an SMS or MMS message application, an email client, and/or any other application that can deliver electronic communications such as the link to the authentication server 110. The user device 120 can display the message and link through one or more of the various messaging interfaces. The link can be selected by the user device 120 to download and install image authentication software 101. The image authentication app 101 may be stored in the user device 120, for example. The image authentication app 101 can program the user device 120 to perform as described in this disclosure. The image authentication agent 101 may program the user device 120 with the appropriate version of the blockchain agent 322. This works in the same way as authentication server 110 except that images, metadata and other information may be written to decentralized ledger 2.
“In an implementation user device 120 can include any device that captures images, including cell phones, smart phone, tablet computers and laptop computers. It may also include digital cameras, webcams, laptop computers or desktop computers. Security cameras, televisions, monitors and the like. Referring to FIG. FIG. 5 shows a device that authenticates image files captured at the device in conjunction with an authentication service. User device 120 could include an electronic imaging system 502, location device 506, one processor 512 and/or additional components.
The image authentication app 101 may ask the user to take one or more digital images upon installation. The image authentication app 101 might open automatically and present an interface for the user to take photos, videos, or any other type of image. An input member may be included to allow the user to take a picture. The image authentication application 101 might transmit images taken without the express permission of the user. The image authentication app 101 may also allow the user to cancel the sending of a photograph (so that another picture can be taken). The image authentication application 101 can generate a hash from a captured image and send it to the authentication server 110. In some cases, the quality of the network connection available to the user device 120 may influence whether or not the image is sent. Nos. Nos.
“In some cases, the user may be allowed to open the image authentication app 101 later. These implementations allow users to open the image authentication app 101 on their user device 120 in order to capture an image. The image authentication 101 101 can record the date and time that the application was opened. It may also track the geographical location of the client device when the application was opened. This information and any other information can be used as metadata later for authentication. The image authentication app 101 can be used to capture an image. It may then generate an image file from the captured image. The image authentication 101 can obtain the date, time, and/or any other metadata during image capture. The image authentication 101 can also assess whether there is a network connection available before allowing users to take the picture. The image authentication app 101 might not allow the user to capture the image if there is no available network connection.
“In certain instances, the image authentication app 101 may be asked by the user to send an image file for authentication. In response, it might determine one or more characteristics about a network connection and decide that the file should not go through the network connection. The image authentication 101 might take additional steps in these cases to verify that the user did not have the chance to modify the image file. This may include securing that certain restrictions and times are met. The image authentication 101 101 might note, for example, when the image authentication app was opened and when the request to send the file was made. The image authentication program may allow further operations to transmit the file if the request to send the file is made within a reasonable time after the image authentication app has been opened. The request to send the image file could be denied, and the file deleted or marked unauthenticated. Image authentication 101 can use additional data to verify the request or replace time information. The image authentication 101 might compare the geographical location of the user 120 at the time that the image authentication app was opened with the location of the device at a time when the user requests transmission to the authentication server 110. This will ensure that the user hasn’t moved a significant distance (e.g. less than 200 feet, or another threshold distance value). The request to transmit an image file could be denied, and the file deleted or marked unauthenticated. These time and geographical requirements ensure that the user does not have enough time to modify the image file.
The image authentication application 101 may place additional restrictions to aid in the authentication process. The image authentication 101 may allow images that were taken within the application 101 to be sent to authentication server 110. The image authentication 101 may also restrict the use of editing tools within the image authentication 101. It may also prevent the export of image files to other programs for editing. The image authentication application 101 makes sure that the image file remains within the approved environment for the entire life of the file. It also ensures that the user is not allowed to modify any part of the file, including metadata or images.
“In cases where the above-mentioned restrictions are used, once the image authentication app 101 has verified that the image file meets these restrictions, it can generate a hash from the image file and then send it to the authentication server 110. The image authentication application 101 can send the file if the network connection is improved or another network connection becomes available. Metadata (e.g. time and location data) may be attached to the image file along with the hash and/or image files. The authentication server 110 does various tasks to authenticate an image file. It also stores the hash file along with the identifying information.
“When the user device 120 receives a copy of the image, the authentication server 110 can generate a server generated hash file using the copy and compare it with the user-generated hash. The match between the server generated hash file and user device generated hash may indicate that the image file copy has not been altered or altered since its original creation (since the image authentication software 101 created the hash file for the original). The authentication server 110 can apply a watermark to the image file or provide other indications that it has been authenticated.
“Electronic image device 502 could include an electronic sensor that detects and transmits information necessary to create an image. An example of an electronic imaging device 502 could include, but is not limited to, a charge coupled device (??CCD?) sensor, a complementary metal-oxide-semiconductor (?CMOS?) Sensor, and/or any other device that detects and transmits information to create an image. An image can include a still image (e.g. a photograph), or a video image and/or other types.
“Network device 504 could include a network device that connects to and transmits data over a network such as network 101 (illustrated at FIG. 1). One implementation may include a network connection 504 for each type of network connection. One network device 504 could be used to connect to a mobile data connection (e.g.?3G/4G/5G/etc.). Provided by a wireless service provider. A second network device 504 could be configured to connect via a Wireless Fidelity (?WiFi?) connection using an IEEE 802.XXX or another specification. There are other types of network connections that allow communication with an authentication server 150 over a network. One network device 504 can be used to connect to multiple network connections in some cases.
“Location Device 506 could include a device that detects information to identify the physical (e.g. geographic) location of the device. Location device 506 could include, but is not limited to, a Global Positioning System (GPS)? A sensor device, a WiFi-enabled device (for accessing hotspot information), a network device for obtaining IP addresses-based physical locations, and/or any other type of location device that can produce information to locate the physical location of the device 506 (and the user device 120).
“In an implementation, one or more processors (512) may be programmed using computer program instructions such as those stored on the one or multiple electronic storage devices 514. The one or more processors may be programmed, for example, by a native camera app 516 or an image authentication software 101. Native camera application 516 could be an executable program, which is different from the image authentication app 101. It captures images with electronic imaging device 502. The native camera application 516 stores the image files it creates in an easily accessible location. This could be a camera directory, which can be readable with an image album program. These image files can be accessed from the accessible location and edited. Image authentication application 101 can be configured with its own image storage and capture functionality to help stop such open access.
“In an image authentication application 101 implementation, there may be various instructions, such as a settings manager 522 and an image file generator 524. A hash file generator 526. A network connection analyzer 528. A decision engine 350. The various instructions are used herein to describe an operation. However, they actually program the processors (512 and therefore the user device 120) to execute the operation.
“User-Defined Setting and System Rules That Control Operation of Image Authentication App”
“The settings manager 522 can obtain from a user one or more user-defined settings that will be applied to the operation of image authentication app 350. The settings manager 522 might expose a user interface that allows a user to set the behavior of the image authentication app 350. You can specify, among other things, which network connections should be avoided, which network connections may allow image files to be transferred, what maximum file size an image file may be uploaded, and/or any other settings that you want to control the behavior or image authentication software 350.
The settings can be combined or used in conjunction with each other. A user might specify that images should not be sent via cellular data connections, but that they can be sent using a WiFi connection. A user might specify that images larger than a specified size should not be sent via cellular data connections. You can also specify other types of network connections or the alternative. Sometimes, an option may be set by the user to prevent image files from being transmitted when a network connection is low quality. This is a low quality? These?low quality? or?strong? qualities may be misleading. Quality may be measured using network latency, network error rate, or other metrics. These metrics can be used to determine if they meet certain quality thresholds. (These may be set by the user and/or predefined in the image authentication app 350). The image authentication application 350 can decide whether or not to send an image file depending on the quality of the available network connection. To determine what quality is acceptable, the network metric threshold can be used. network connection and what is a strong? network connection. Not all quality metrics can be used. A combination of quality metrics can be used to create an overall network score. This score may be compared with a network quality threshold. These threshold values can be predefined using a user-defined setting or a system rule (described below).
The settings manager 522 can obtain predefined system rules to control the operation of the image authentication app 350. Predefined system rules can include settings that are identical to the user-definable settings. However, instead of being set manually by the user, predefined system rules could be created by developers or other people who are not end users of the user device 120. In this way, some system rules may offer default settings that correspond to the user-defined settings. Other implementations may not allow any user-defined settings, and only the system rules can be used.
“Capturing and Generating Image Files”
“Using the electronic image device 502, image generator 524 can capture an image and create an image file. Depending on what type of image is captured (e.g. photograph, video, etc.), the file size can be adjusted. Image file generator 524 can encode captured images into image files using the appropriate encoding techniques (e.g. JPEG/PNG/etc. MPEG/NTSC/etc. for photographs Videos, etc. Image file generator 524 can store the image file at a file location on an electronic storage device 114. This is known as hidden file location. This hidden location is not visible to user device 120 but can be accessed by the image authentication app 350. The hidden location could be hidden from the user by using native operating system hidden directory techniques. You may also use other file locations.”
“Generating Hash Files.”
“In certain implementations, the hash generator 526 might generate a hashfile based on an images file. The hash generator 526 might generate a hash from the image file by using a hash function, and then generate the hash files based on that hash. Some implementations may use the hash function to map data from an image file into data with a fixed size. This fixed size (e.g. memory footprint) can be smaller than the size of the image. Depending on the size and content of the image files, the fixed size may be orders of magnitudes smaller than that of the image files. The content of an image file may be used to generate a hash function that is deterministic. If the copy has not been altered, the hash of an image file generated by the hash function will match the hash of its copy. A hash function will make it so that a hash for an image file is different from a hash for a modified copy (and even a hash for another file). The authentication server may use a similar hash function. Some examples of hash functions that could be used are SHA256 and SHA512.
“Assessing Network Characteristics.”
“In an implementation, a network connection analyzer 528 might determine one or more characteristics for an available network connection. An available network connect is one that can be established or detected by one or more network devices 504 (e.g., network connections in which broadcast network information has been detected from an access points associated with the connection, network connections in which communication has been established with an accesspoint associated with the connection, network connections in which initial handshake communication with an access station associated with the connection, etc.). One or more characteristics could include, but are not limited to, the type of available network connectivity, the quality of an existing network connection, and/or any other characteristics that define an available connection.
“Types of Network Connectivity”
“In certain implementations, the network connector analyzer 528 might determine types of network connections. The network connection analyzer 528 might identify the type of network connection that is currently being used to transmit data from or to the user’s device 120 via network 102. The network connection analyzer 528 might determine that a network device 504 is connected to a cell network and is being used to transmit or receive data from the user’s device 120. Similar connections may also be made, such as WiFi connections. If configured, one can obtain the types of network connections from the operating system 120 or from the network device 504 in some cases.
“As we will describe, the decision engine 350 may use the type of available internet connection to determine whether to send a hash of an image file or whether to send the image.
“Quality of Network Connections.”
“In some cases, the network connection analyser 528 can determine the quality of one (or more) available network connections. One or more metrics may be used to assess the quality of a network connection. One or more metrics could include a signal strength indicator (or vice versa), a number dropped packets (or vice versa), a ratio received packets to dropped packets (or both), and/or other network quality metrics that can help to evaluate the quality of an available connection.
The network connection analyzer 528 can determine the signal strength of an existing network connection in some cases. A measurement of the signal strength can be taken from access points, such as a signal transmitted by a cellular basestation, a signal transmitted via WiFi router or another WiFi access point, or a measurement taken from an access station of the signal transmitted by the user device 120 to that access point and/or any other signal measurement.
“In certain instances, the network connectivity analyzer 528 might determine a number dropped packets from information that was exchanged between access points (e.g., a cell network base station, WiFi router, etc.). and user device 120.”
The network connection analyzer 528 might determine if there are dropped packets relative to received packets, and/or a ratio. The network connection analyzer 528 might determine a burst rate or other network transmission metric, which can be used to determine a number of dropped packets relative to received packets.
“In certain instances, the network connectivity analyzer 528 might be able to determine the current throughput of the first available network connection. The throughput can be determined based on information about the network performance exchanged between user device 120 (e.g. using control channels) in some cases. The network connection analyzer 528 can sometimes obtain upload throughput by sending one or more predefined data sets with known sizes to a networked device (such authentication server 150). The network connection analyzer 528 can transmit a predefined list of data to the networked devices and calculate the time it took for that set of data (based on acknowledgement receipts from the networked devices). The size and time of the data set may be used by the network connection analyzer 528 to determine throughput. Alternately, or in addition, the network connection analyser 528 can receive the length of the set of data and/or throughput calculation from the networked devices.
“In some cases, the network connection analyser 528 may obtain the download throughput using the same techniques as the upload throughput. However, instead of measuring the transmission of data from user device 120 to networked, the user 120 and/or networked devices measure the data transmitted from the networked to user device 120. The upload throughput and/or download throughput can be used to guide the decision-making process.
“In some cases, the network connectivity analyzer 528 might obtain the current latency of the first available network connection. The latency can be determined based on information about the network performance between user device 120 (e.g. using control channels) and access point. The network connection analyzer 528 can sometimes obtain latency by sending or receiving predefined data sets with known sizes to a networked device (such authentication server 150). The network connection analyzer 528 can transmit a predetermined set of data to the networked devices and calculate the time it took for that set to reach the device. This is based on acknowledgement receipts from the networked devices. The length of time may be used by the network connection analyzer 528 to determine latency. Alternately, or in addition, the network connection analyser 528 can receive the length and/or latency calculation from the networked devices. Sometimes, the length of time can be used to calculate latency.
“It is important to note that multiple network connections may be available. as described herein. The network connection analyzer 528 can be used in these cases to determine the characteristics of a current network connection being used to transmit data from or to the user device 120 via a network such as network 101.
“Decision Engine”
“In some cases, the decision engine 350 can decide whether to send an image file or a hash of the image file depending on the characteristics of a network connection. The decision engine 350, for example, may get one or more characteristics from network connection analyzer 528 and decide that an image file should be transmitted instead. This is based on one or more characteristics of the current network connection available at the time. The decision engine 350 can periodically acquire characteristics of a network connection after the hash file is transmitted. The decision engine 350 might, for example, determine that the image file can be sent by obtaining characteristics of a network connection at a later time.
“The decision engine 350 may decide that the image file should not be sent the first time, but it can take place in a variety of situations. One example is that network conditions, such as quality, may have changed from the first to the second time. This could be the case where signal strength, successful versus dropped packet ratio, latency and/or other quality indicators have improved above a threshold level, whereas they were lower at the first time. Another example is that a second type or network connection might have been available at the second time, but not at the first. While the first network connection is able to send images files, the second network connection can be used for that purpose. Image files can be sent on a WiFi network, but not on a cell network. While a cellular network connection was available initially, a WiFi connection might have become available later. The system rules and user-defined settings may dictate the logic in some cases.
“In certain instances, system rules and/or user defined settings may specify one or several threshold quality values. Each threshold quality value may correspond to a different type of network quality assessment. As an example, the following could be used to define a threshold quality value: A minimal signal strength indicator value can be used to determine a threshold quality value (below the threshold quality threshold 350 is considered a ‘poor quality?). connection, and above which decision engine 350 considers to be a’strong? connection), a predefined value for dropped packets (above which decision engine 350 considers to be a ‘poor quality? connection, and below which the decision engines 350 consider a’strong? Connection), the ratio of dropped packets to received packets (below which decision engine 350 considers a “poor quality?” connection, and above which decision engine 350 considers to be a’strong? connection), a network latency (below which decision engine 350 considers to be a ‘poor quality? connection, and the decision engine 350 considers it a’strong? connection), a network throughput (below which decision engine 350 considers to be a ‘poor quality? connection, and above which decision engine 350 considers it a’strong? connection and above which the decision engine 350 considers a?strong? connection. Implementations that combine one or more of these factors may have a threshold value predefined to reflect a combination score. The decision engine 350 can determine whether there is a weak or strong connection based on whether the network quality metric (e.g., it is higher or lower depending on the threshold value) differs from the threshold value.
The decision engine 350 can determine whether an image or hash file should go out based on a comparison of the current quality metric with the threshold value. For example, if the file is of poor quality? For network connections, it is possible to send the hash file but not the image file. For?strong?” The image file can be sent to network connections.
“FIG. “FIG.
“In an operation 602, 600 could include receiving a request for one or more electronic images that need to be authenticated. A request could include an electronic address from which the user can obtain one or more electronic photos. A 600 operation may also include the obtaining of a unique identifier for the request. The system can generate the unique identifier or provide it in the request. An operation 606 may involve 600 generating a link that allows you to download an application. The link will contain the unique identifier as well as a location on the network from which the application can be downloaded. A 608 operation 600 could include sending a message containing the link to the electronic address to the user. The link, when selected, causes the user to choose the link to download and install the application. In operation 610, 600 could include receiving an electronic picture from the application. The electronic image was generated at user device by application. An operation 612 may also include 600. This process could be used to authenticate the electronic image. Process 600 in an operation 614 may provide access to the electronic images and indicate the authentication to the requester.
“FIG. 7 illustrates a process 700 to locate, install and open an image authentication app 101 for generating and uploading images for authentication. This is according to an implementation. “In an operation 702, process 700 might include”
“In operation 704, process 700 could include receiving a link to download an image authentication software 101. The link could specify a download location or encode a unique identification. A 700 operation may involve downloading, installing, opening, and closing the image authentication app 101 in response to the user’s selection of the link. A 708 operation may involve generating one or more images with the image authentication app 101. This is independent from the native camera application 516. Process 700 in an operation 710 may involve transmitting the unique identification with the generated images and hash for each image, metadata, or other information to authentication server 110. It is important to realize that authenticated images are useful and beneficial in many applications. For example, inspection companies can use authenticated images to document property inspections or financial companies to help them?know your customer?. To ensure that users are accurate and current images, authenticated images can be requested from documents such as utility bills, dating websites, social media, casting directors, etc. To verify the activities and whereabouts their children are, parents can request authenticated images. Users can request images related to their experiences. They can also view images of friends with complete faith that they are accurate representations of their activities. You can track your package and get location information from delivery services. Customers making online purchases or reservations can request and verify the condition of the item they are purchasing or the item/property/vehicle they are renting. Information about the source images can be requested by news outlets. Witnesses can provide reliable and verifiable photos taken on the scene of a crime or accident upon request. These are just a few examples of the many uses for authenticated images.
“FIG. “FIG. 8” shows a screen shot of a landing page interface 800 from the interface portal 216, as provided by the system in accordance with an implementation of the invention. Like reference signs are used to refer to the same component in each interface (e.g. 800-1100). The interfaces 800-1100 are merely for illustration purposes. Many interface components can be modified, added or removed as needed. After logging in, an administrator of an entity wishing to get authenticated images from its customers may display the landing page interface 800 via interface portal 216. The landing page interface 800 could be used to present photos of damage to insured property to an insurance adjuster.
“The landing page interface 800 could include a white-label 801 which provides graphics and/or texts to give a look and feel of the entity, a search output 803, a new inspection hyperlink 810, a ready-to-review link 820, an inspection workflow URL 830, and/or any other interface components. Display options may be available for searching the computer system 104 using search terms. Search terms could include search terms for users, such as insured users and/or any other terms.
“The landing page interface 800 could include links to other pages. The New Inspection link 810 may display an image request interface, for example. FIG. 9. When you select the Ready to Review link 820 it may display a list of inspections that have images uploaded by users. An inspection view interface can be displayed after selecting an inspection. FIG. 10. When you select the All Open Inspections link 830 it may display an inspection listing interface. FIG. 11. When you select the Recently Viewed link, 840, a list of recent image requests may be displayed.
“FIG. “FIG. 9” shows a screen shot of an image request interface (900) of the interface portal 216, as provided by the system in accordance with an implementation of the invention. Image request interface 900 can include input options to receive parameters from users in order to request authentication images. The image request interface 901 may contain a name input 901 to receive a name from which to request images. An electronic address input 903 is used to send a link to an image authentication app 101 to the user. A user ID input 905 can be used to input an identifier, such as a claim number, or any other identifier. A note input 107 allows for the receipt of a note that will be delivered to the recipient. Finally, a send input 909 sends the request to user. A message preview 911 may be available on the image request interface 900. This preview shows how the message will look to the recipient.
“FIG. “FIG. 10” shows a screen shot of an inspection interface 1000 of the portal 216. This interface is provided by the system according to an implementation. An inspection view interface 1000 could include a portion 1003, which allows users to upload images and provide information about the inspection. An inspection view interface 1000 could include a location panel 1010, status pane 1020 and images pane 10030.
“The location pane 1010 can include a visual and/or textual indication of a place from which images were taken or transmitted by the user via image authentication 101. Examples (as shown) display a message that indicates the location is not available if an image hasn’t been uploaded yet. The location pane 1010 may display the image’s location. Multiple images may be uploaded. The location of each image can change when it is viewed at the images pages 1030.
“The status pane 1020 can include information about the status of the inspection, such as images authenticated, images awaiting images, images failed authentication, reasons for failure, and so on. A status pane 1020 could include an event log 1014 which lists all events related to the inspection. The event log could start with the initial request by the user for images. It may also track any subsequent activity since that request.
Summary for “Proof of Image Authentication on a Blockchain”
Since its inception, digital photography has seen steady growth. The growth in photographic data available to the public has been further accelerated by social networks and mobile computing devices. Because it is easy to share and take photos anywhere and anytime, the public has become more dependent on these photos for the most up-to-the minute information. It is well-known that digital photos can be easily edited, and therefore the information in a digital photo may not always be trustworthy. Digital photographs and electronic images can be used to create trustworthy evidence (also known as “images”). It can be difficult to obtain trustworthy evidence based on digital photographs and other electronic images (also referred to herein interchangeably as?images?). This is because technology can alter or compromise the integrity of these images. These problems and others are present with traditional image collection systems and authentication systems.
“Authenticated photos are useful in many cases, especially when the photo is used to prove or support a fact or set facts. Many industries face technical issues related to remote inspections and virtual underwriting. A trusted inspector needed to visit a business, property or asset in person to conduct an inspection. This can be costly and time-consuming.
“The technology allows remote inspections. This technical solution has created other problems. There are many technologies that allow images, location data and metadata to be altered easily. This is a common problem with images (photos and video) being used to facilitate remote inspection.
“One example of this is when it comes to insurance claims. There are many applications and technologies that allow an unscrupulous user in the context to metadata manipulation, location-spoofing, photo manipulation, taking photos of other photos, and using images from the Internet that purports to be images that the user captured. These technical issues can have a negative impact on the integrity of claims or underwriting.
These and other technical issues exist in many industries, in many contexts in which image data is submitted instead of an in-person physical examination.
“The invention is a technical solution that addresses these and other issues in relation to the use of technology to authenticate electronic images and provide proof that they have not been altered.”
The authentication server might authenticate one or more images. This authentication could include, among others, performing a reverse search of each one or more electronic image using an image platform. To determine if a match is found, the electronic images can be compared against a list of electronic images. This may involve creating a hash from the image and/or using an image authentication app executing on the user device. The hash can then be searched and compared against each image in the electronic image database. The hashes might match, indicating that the uploaded electronic image is not authentic. The image could, for example, be an image already taken by the image authentication app or copied from an internet search and uploaded (assuming that it was tampered with).
“Other methods may also be used for authentication. The image authentication application might transmit metadata to the authentication servers that can be used to authenticate. The metadata can include information about the time and/or location of images that can be used for authentication. The metadata could include information such as the time and/or place at which the image authentication software was downloaded, installed and opened. It can also contain images that were generated and uploaded. This information may be used to determine how long it took or how far distance was traveled between events of interest. The picture might not be authenticated if it takes longer than the predetermined time period from the application installation to the taking of the picture. This could be because the user had the time to compromise the image and/or application. Sometimes, the location of the user based on metadata can be compared with an expected location (e.g., a home or work address) which could be provided by the requesting entity, such as the insurance company. The picture may not be authenticated if the distance between the expected location and the user’s location is greater than a predetermined distance.
The authentication server can provide one or more electronic photos, any associated metadata and indication of authentication (or failed authentication, reason for failure), the unique identifier and/or additional information through the portal UI. The requesting device can then obtain one or more electronic photos, which may be authenticated.
“In some instances, the various processes described herein could generate a transaction that can be transmitted to a Blockchain network. The transaction could be written as a block on the decentralized ledger. The image authentication application might generate and transmit transactions each time an image is taken, uploaded or at any other time. An authentication server might generate and transmit transactions each time an image is received, authenticated, or at other times. A hash of the image generated by the image authentication app may be included in the transaction’s payload. The decentralized ledger may contain an immutable record of each image at different stages. The decentralized ledger may contain the hash of the image at each stage of the process: upload, generation, authentication and/or any other. These can be compared to ensure that the images are not altered.
“In some cases, an image authentication application on the user device might generate an image for authentication. The image authentication application might generate an image hash using a hash function such as a one way hash function. The authentication server may receive the image from the image authentication app. The image hash may be written to the blockchain by the user device. A record of the image hash can be made on the blockchain. This records the state of an image after it is generated by an image authentication app and before it is transmitted to an authentication server.
“In some cases, after receiving the image, an authentication server may generate an image haveh using the hashing functions (e.g. the same hashing algorithm used by the image authentication app). The image hash generated by the authentication server can be written to the blockchain. A record of the image hash can be made on the blockchain. This records the state of each image once it has been received. You can generate image hashes during authentication, and then write the hashes to your blockchain. A record of the image hashes may be kept on the blockchain. This records the state of an image at different times during and/or following authentication. To prove that an image is not altered or altered between different points in time, the hashes of the image stored on the blockchain may be retrieved. The image hashes can be compared to prove that the image was not altered from the moment it was created to the time it is uploaded to the server.
“While the examples above and others may have been used to illustrate an insurer asking for authenticated images from its insureds, the system can be used in many other situations in which an entity wants to obtain images from users to verify their authenticity.”
These and other features and characteristics of the system/method disclosed herein, along with the methods of operation, functions, and combinations of parts and economies, will be more obvious if you read the following description and refer to the attached claims. All of these forms a part this specification. In which like reference numbers designate the corresponding parts of the various figures, The drawings should be understood that they are intended to illustrate and describe the invention and not as a limitation of its capabilities. The singular forms of?a,?an, and??the are used in the specification as well as in the claims. If the context requires otherwise, include plural referents
According to one aspect, a variety of disclosed systems and methods can authenticate images based upon requests from entities to obtain authenticated electronic images from users. An entity could include an insurance provider, which requests that its insured upload images related to an insurance claim. These images might be images documenting damage to a vehicle. In order to reduce fraudulent claims, the system can provide a special application that can be installed on a user’s device. The insurance provider might request images from its insured and send it to the authentication server. An electronic address may be included in the request. An authentication server might provide a link to the electronic adress. The link could include a network address from which you can download the application, as well as a unique identifier that is associated with your request. After the insured selects the link, the insured’s user device can download the application. This application is separate from native camera applications and may generate one or several images. The images can be transmitted to an authentication server along with their unique identifier to prevent tampering. An authentication server can authenticate an image by comparing it with a list of images. The authentication server might perform a reverse image search of the image. The authentication server can also authenticate the image using alternative or additional methods. The unique identifier was used to identify the images. The authentication server can provide images and metadata, as well as authentication results, to the insurer.
“FIG. “FIG. 1” illustrates a system 100 for authenticating electronic images according to an implementation. System 100 could include an authentication server 110 and one or more user devices 120. A linking system 130, an imaging platform 140, an application store 150, a network 1 consisting of multiple nodes 10, a distributed ledger 2 made up of multiple blocks 3 and/or other components. System 100 components may communicate with each other via a network 101.
“Refer to FIG. 2. This diagram illustrates a data flow 200 for authenticating electronic images according to an implementation. An interface portal (?UP?) may be generated by the authentication server 110. The authentication server 110 may generate a portal user interface (?UP?) through which the requesting devices 108 can request authenticated images from the authentication server 120. One or more input options may be provided by the portal UI 211 to allow the user to specify the request parameters for authenticated and secure images. The portal UI 211 can receive, for example, a name and an email address of a user at operation 201. It may also receive a client-generated identifier, such as an insurance claim number, an expected location of a user (e.g. a home or office address), a note and/or any other information necessary to request the authenticated images.
“At operation 202, portal UI 211 might receive the request parameters. They may then forward them to authentication server 110.”
“At operation 204, an authentication server 110 might generate one or more links parameters and send them to the linking network 130 to create a link to the user’s electronic address. Link parameters can include an electronic address from which you can download the image authentication application 101, an unique identifier and/or any other information. The link parameters can be based on any one or several of the request parameters in some cases. The client-generated identifier could be included in the unique identifier. To track the request, the authentication server 110 may generate the unique identifier. Each image authentication application 101 can be customized to suit the needs of each entity. The image authentication 101 might be white-labeled to each requester entity, for example. These implementations may allow the authentication server 110 to identify the requesting entity and to identify the appropriate image authentication 101 (such as one that was white-labeled to the requesting entities) that will be sent to the user’s electronic address. Other implementations may contain a single application in the image authentication 101. The unique identifier may allow the single application to customize its content (including appearance and feel). Each unique identifier can be associated with a corresponding entity. This allows the application to create custom content based upon the identity of the entity.
“At operation 206, the linking software 130 may create a link using the link parameters.” The link could encode the electronic address from which the image authentication application 101 can be downloaded and the unique identification.
“At operation 208, authentication server 110 may transmit a link to the electronic adress. The authentication server 110 might generate a message with the link and send it via the appropriate communication channel. The authentication server 110 can transmit the message via a Short Message Services (?SMS) if the electronic address is a mobile number. Multimedia Messaging Service, (?MMS?) Text message. The authentication server 110 can transmit the message electronically if the electronic address is an email address. Depending on the type of electronic address, other types of electronic communication can be used to send the message.
“At operation 210, user device 120 might receive the link to download the image authentication app 101 from the app store 150. An app store 150 could include an app store from a third party such as APPLE APP SHOP STORE or GOOGLE PLAY. An internal app store may be included in the app store 150 provided by authentication server 110.
“If the electronic address refers to a mobile number, the user device 120 could include a mobile telephone that displays the message as a text message. The message might invite the user to interact with the link to download image authentication software 101.
“At operation 212, app store 150 may identify an image authentication application 101 based upon the link and transmit it to the user’s device 120. The app store 150 might store multiple image authentication apps 101 that are white-labeled to a particular entity. The user device 120 can download and install. All of the above may be done automatically, without user intervention. The user device 120 might open the image authentication app 101 automatically in some cases. In other instances, it may respond to user input (such as selecting the icon that corresponds to the application). The unique identifier encoded within the link may be included in the image authentication app 101. The image authentication application 101 might store the unique ID in hidden fields that are used to submit the authentication server 110. There are other ways to store and send the unique identifier. The image authentication app 101 may store the unique ID without the need for user intervention at the device 120. These implementations may not require the user to register in order to use the image authentication app 101. After downloading and installing, the image authentication software 101 may be used for one or more electronic images to be authenticated.
“An operation 214 allows the user device 120 to generate and transmit one or more electronic images along with related data (such a hash of an image, metadata, EXIF, or similar data) at the authentication server 110.
“At operation 216, authentication server 110 might authenticate one or more images. This authentication could include, among others, performing a reverse search of each one or more electronic images via image platform 140. To determine if a match is found, the electronic images can be matched against an electronic image database 140. This may involve creating a hash from the image and/or using the image authentication app 101 executed at user device 120 to search for it. The hash is then compared against each image in the electronic image database. The match between the hashes could indicate that the uploaded electronic image from user device 120 is an existing one, which may mean that the image is not authentic. The image could, for example, be an image already taken by the image authentication app 101 or copied from an internet search and uploaded (assuming that it was tampered with).
The image authentication server 110 might obtain the results of the reverse-image search from the image platform 140 at an operation 218, Other authentication methods may also be used, including comparing metadata that indicates the location where the image is generated with the expected location (e.g. comparing the time at the which image authentication 101 was downloaded with the time at the which the images were taken or uploaded. Likewise, comparing the time at the which image authentication 101 was downloaded with the time when an image of that location was taken and the location where it was uploaded. Using other validation techniques, you might compare the location in which image authentication 101 was opened with the location at the which image was created. These time and/or geographical requirements ensure that the user does not have enough time to modify the image file.
“At operation 220, authentication server 110 can provide one or more electronic pictures, any associated metadata and indication of authentication (or failed authentication, reason for failure), the unique identifier and/or additional information through the portal UI 201. The requesting device 208 can obtain one or more digital images that have been authenticated. Even though the information is not illustrated, it may be written to decentralized ledger 2, for immutable storage or authentication.
“Referring to FIG. The blockchain network 1 could be made up of multiple nodes 10. Minimum one of the nodes might include its own copy the decentralized ledger. Multiple blocks may make up the decentralized ledger 2. Each block refers to a previous block’s hash. A variety of processes described herein may result in a transaction that is transmitted to the blockchain network 1. (e.g. to one or more peer-to-peer communication protocols). The transaction can be written to block 3 of the decentralized ledger. The image authentication application 101, for example, may generate and transmit transactions each time an image has been taken, uploaded, or at any other time. An authentication server 110 could generate and transmit transactions each time an image is received, authenticated and/or at another time. A hash of the image created at image authentication application 101 may be part of the transaction’s payload. This will allow for an immutable record of each image during various processes or stages. To verify that an image is not altered during these processes, one can retrieve the hash of the image at upload, generation, authentication and/or other times from the decentralized ledger 2.
“FIG. “FIG. One or more processors 312, one, or more storage devices 314 and/or other components may be included in the authentication server 110. Instructions that program the processors may be stored on one or more of the storage devices 314 One or more storage devices 314, may contain instructions that program one or more physical processors 312.
“The interface portal 31 may create one or more interfaces to receive requests from users for authenticated images. The portal UI 211 may be generated by the interface portal 316. The interface portal 316 might implement multiple layers of authentication in some cases. The authentication server 110 might have registered clients previously to allow them to use the system to request authenticated photos from users. Clients may register one or several of their requesting devices (108 or network gateway). The system could store, for example, valid Internet Protocol (?IP?) addresses. The system may store valid Internet Protocol (?IP?) addresses that are associated with registered clients. The interface portal 316 can whitelist IP addresses to allow a requesting device’s IP address 108 to be compared with whitelisted IP addresses previously registered. You may also use other layers of authentication, such as secret key/password or other authentication mechanisms.
The portal UI 211 may have one or more input options that allow users to specify the request parameters for authenticated and secure images. One or more user input options can be used to request a user’s name (e.g. person or entity), an electronic address, a client-generated number (e.g. an insurance claim #), an expected location (e.g. a home address or work address), and a note about the user.
“In certain cases, the client-generated ID may be stored together with a user login used for authentication. An example is that an insurance provider might have multiple claim staff to handle insurance claims. This could be because the claim number, which may also serve as the client’s identifier, may be used by an entity like an insurance company. The portal UI 211 can display the insurance personnel with the claim numbers that they are handling upon login by claim personnel. The portal UI 211 may present the claim number and any relevant images or other information that was collected by the system.
“Responsive” to the request for authentication images, the link generator 318 might identify the entity that made the request. Based on the identity of the requester, the specific white-labeled photo authentication application 101 can be identified. The link generator 318 can encode the link using a download location for white-labeled photo authentication application 101 and a unique ID, which could be either a client-generated or system-generated identifier. The request parameters may include the client-generated or system-generated IDs. Sometimes, the link can be generated as bitly code, tinyURL or a combination of both. This URL may then be associated with a full URL that includes parameter inputs. In this case, the parameter input may contain the unique identifier. The link generator 318 will send a message with the link to the email address provided in the request for authenticated images. The message can include the following: the request, client-generated ID, unique identifier (if it is different from the client’s identifier), contact information and/or any other information. The link generator 318 can provide multiple messages related to each other in order to create a conversational atmosphere. For example, it may include a claim number and contact number in separate messages. The authentication server 110 can receive images from the image authentication app 101 after it is installed and executed on a user device 120.
The server-based image authentication app 320 can authenticate one or more images in a variety of ways. The server-based image authentication app 320 might authenticate one or more images through a reverse image search. Each of the electronic images can be matched against a list of electronic images in order to find a match. This may involve creating a hash from the image and/or using the image authentication app 101 executed at user device 120 to search for it. The hash is then compared against each image in the electronic image database. The match between the hashes could indicate that the uploaded electronic image from user device 120 is an existing one, which may mean that the image is not authentic. The image could, for example, be an image already taken by the image authentication app 101 or copied from an internet search and uploaded (assuming that it was tampered with).
Other authentication methods may also be used, such as comparing metadata that indicates a place at the which the photo was created with an expected location (e.g. comparing the time at the which the picture authentication app 101 was downloaded with the time at the which the images were taken or uploaded. Similarly, comparing the time at the which the file was downloaded with the time when the image upload was made to the authentication servers 110. Likewise, comparing the location where the image authentication software 101 was opened with the location where an image is being uploaded. These time and/or geographical requirements ensure that the user does not have enough time to modify the image file.
“These and other authentication technologies described in greater detail with regard to FIG. 4 and U.S. Patent Application Ser. No. No. Filled Aug. 3, 2015 (issued under U.S. Pat. No. No. 9.300,678 Mar. 29, 2016), and U.S. Patent Application Ser. No. No. 15/728.869 entitled?METHODS TO AUTHENTICATING PHOTOGRAPHIC IMAGE DATA? Filed on October 10, 2017, and the contents are hereby incorporated herein in their entirety.”
“The blockchain agent 322 might generate a transaction that can be transmitted to a Blockchain network. The transaction can be written to the decentralized ledger as a block. The blockchain agent 322 could generate and transmit transactions every time an image is taken, uploaded and/or at any other times (when the user device 120 is connected). When the authentication server 110 is used, the blockchain agent 322 can generate and transmit a transaction for each image received, authenticated and/or at any other time. A hash of the image generated by the image authentication app may be included in the transaction’s payload. The decentralized ledger may contain an immutable record of each image at different stages. The decentralized ledger may contain the hash of the image at each stage of the process: upload, generation, authentication and/or any other. These can be compared to ensure that the images are not altered.
“FIG. “FIG. The server-based image authentication app 320 may program some implementations so that the authentication server 110 can process some or all of the restrictions set by the user device 120. The authentication server 110 might receive information from the image authentication app 101 about time, location, and/or any other information that could be used to determine if the user had enough time to modify an image file. The image authentication app 101 may perform some or all the assessment described in FIG. 5 below. Authentication server 110 can then authenticate the image file in such cases, but only if such assessments indicate that the user did not have enough time to modify the file.
The authentication server 110 might use some of the geo-information (e.g. coordinates) received from user device 120 in different ways. The image authentication 101 might ask the user to identify the place where the photograph was taken. This information could be sent to the authentication server along with the application-recorded coordinate information. To verify that the information is accurate, the authentication server 110 can compare the recorded coordinate information to the address/points of interest information. Alternativly, the authentication server 110 can use coordinate information from the image authentication app 101 to search for the corresponding address or points of interest nearby and then suggest addresses/points that might be of interest to the user. Although the user has the option of including or removing geographic information from the authenticated image file, it is forbidden to modify or add unverifiable information.
“The authentication server 110 might create a resource locator identifier that is associated with authenticated image files and/or watermarked images so that third-party viewers can visit the URL to confirm that the image has indeed been authenticated. A web address, or a shorter web address, may be used to identify the resource location. This will direct third-party viewers to a website where they can view the authenticated and/or watermarked images. Third party viewers may upload a copy of the authenticated and/or watermarked image to the URL so they can compare the image they received with the authenticated one at the address. A third-party viewer might receive an image file that is allegedly authenticated by a user of the photographic authentication system. A watermark may be added to the image file to indicate that the photograph is authentic. It is possible, however, that the watermark was falsely applied to unauthenticated or edited images. The third-party viewer can visit the URL associated with the image to verify that it has been authenticated and not altered in any way. The web address can be included in the watermarked image (e.g., it may be part or all of the watermark), provided by the sender, or embedded in the image so that the user can click on the watermarked photo to go directly to the address. The web address can be either the complete address or a representation (e.g., a QR Code, tinyURL or bitly address) of the address. A third party viewer can check that the authenticated photograph is authenticated by visiting the URL.
“In some cases, authenticated metadata may be included by the authentication server 110. This includes server-applied date stamps, server-applied timestamps and geographical information. An authenticated file may also contain a resource location ID. This resource location identifier can be either a web URL or a representation thereof (e.g. bitly code or tinyURL or QR code). This scenario allows the authenticated file or a portion of the authenticated file to be uploaded to a website that is viewable by third parties. To show that the image has not been modified or revised, the user can share the authenticated file with third-party viewers. Third-party viewers can access the authenticated file and the URL to verify that the image was not altered or revised.
The authenticated file can contain any combination of authenticated images (i.e. the original image after it has been verified and verified by authentication server), authenticated metadata (e.g. authentication server-provided timestamps, datestamps and geographical data) and/or watermarked images. A watermarked image is the authenticated photo with a visual watermark attached to it to indicate that it has been validated by authentication server. Now, we will be focusing on the components of the above and other implementations.
“Having discussed various methods of determining whether a user had the time to modify an image file, and the results of authentication authentication, our attention now turns to authentication server components 120 that facilitate these functions and others. One or more physical processors 312, electronic storage devices 314, or other components may be part of authentication server 110.
“In an implementation, one or more physical processors 312 may be programmed using computer program instructions such as those stored on the one or multiple electronic storage devices 504. One or more of the physical processors 312 could be programmed, for example, by a server-based application 320.
“The server-based image authentication app 320 may contain various instructions, including a hash generator 412, network connection analyzer 414 and/or authentication engine 416. The various instructions are used herein to describe an operation. However, they actually program the physical processors 312 and authentication server 110 to perform the operation.
“In an implementation hash generator 412 is identical to hash generator 526 used in the image authentication app 101 illustrated in FIG. 5. This allows for a hash file to be generated at both the authentication server 110 or the user device 120. Examples of hash functions that can be used by the hash file generator 412 include SHA256 and SHA512. A database may contain multiple versions of different hash file generators in some implementations. A database can be used to retrieve the appropriate version of a hash generator if different versions are being used on different user devices 120. These implementations may allow user device 120 to communicate information that identifies the hash file generator type or version used. This information could be an image authentication app version, an identifier of the hash generator and/or any other identifying information used to identify authentication server 110 in order to retrieve the correct hash generator.
“In an implementation, the network connection analyser 414 can participate in network connectivity analysis and/or perform functions of the 528 network connection analyzer used by the image authentication app 101 illustrated in FIG. 5. This allows the authentication server 110 or the user device 120 to assess the quality and reliability of the network connection through which the authentication servers 110 and 120 communicate.”
“In an implementation, authentication engine 416 facilitates authentication image files captured at user device 120, even though use of a network connection for image files from user devices 120 to authentication server 110 should be limited (e.g. to minimize cellular data and/or when there is no network connection). The authentication engine 416 might receive an image file hash file from user device 120. The hash file is typically smaller than the image file so it can be sent over a cellular network or “poor” internet connection. The connection may be more efficient if it is of high quality (as discussed herein).
“FIG. “FIG. The user device 120 can provide various conventional messaging interfaces (not shown), such as an SMS or MMS message application, an email client, and/or any other application that can deliver electronic communications such as the link to the authentication server 110. The user device 120 can display the message and link through one or more of the various messaging interfaces. The link can be selected by the user device 120 to download and install image authentication software 101. The image authentication app 101 may be stored in the user device 120, for example. The image authentication app 101 can program the user device 120 to perform as described in this disclosure. The image authentication agent 101 may program the user device 120 with the appropriate version of the blockchain agent 322. This works in the same way as authentication server 110 except that images, metadata and other information may be written to decentralized ledger 2.
“In an implementation user device 120 can include any device that captures images, including cell phones, smart phone, tablet computers and laptop computers. It may also include digital cameras, webcams, laptop computers or desktop computers. Security cameras, televisions, monitors and the like. Referring to FIG. FIG. 5 shows a device that authenticates image files captured at the device in conjunction with an authentication service. User device 120 could include an electronic imaging system 502, location device 506, one processor 512 and/or additional components.
The image authentication app 101 may ask the user to take one or more digital images upon installation. The image authentication app 101 might open automatically and present an interface for the user to take photos, videos, or any other type of image. An input member may be included to allow the user to take a picture. The image authentication application 101 might transmit images taken without the express permission of the user. The image authentication app 101 may also allow the user to cancel the sending of a photograph (so that another picture can be taken). The image authentication application 101 can generate a hash from a captured image and send it to the authentication server 110. In some cases, the quality of the network connection available to the user device 120 may influence whether or not the image is sent. Nos. Nos.
“In some cases, the user may be allowed to open the image authentication app 101 later. These implementations allow users to open the image authentication app 101 on their user device 120 in order to capture an image. The image authentication 101 101 can record the date and time that the application was opened. It may also track the geographical location of the client device when the application was opened. This information and any other information can be used as metadata later for authentication. The image authentication app 101 can be used to capture an image. It may then generate an image file from the captured image. The image authentication 101 can obtain the date, time, and/or any other metadata during image capture. The image authentication 101 can also assess whether there is a network connection available before allowing users to take the picture. The image authentication app 101 might not allow the user to capture the image if there is no available network connection.
“In certain instances, the image authentication app 101 may be asked by the user to send an image file for authentication. In response, it might determine one or more characteristics about a network connection and decide that the file should not go through the network connection. The image authentication 101 might take additional steps in these cases to verify that the user did not have the chance to modify the image file. This may include securing that certain restrictions and times are met. The image authentication 101 101 might note, for example, when the image authentication app was opened and when the request to send the file was made. The image authentication program may allow further operations to transmit the file if the request to send the file is made within a reasonable time after the image authentication app has been opened. The request to send the image file could be denied, and the file deleted or marked unauthenticated. Image authentication 101 can use additional data to verify the request or replace time information. The image authentication 101 might compare the geographical location of the user 120 at the time that the image authentication app was opened with the location of the device at a time when the user requests transmission to the authentication server 110. This will ensure that the user hasn’t moved a significant distance (e.g. less than 200 feet, or another threshold distance value). The request to transmit an image file could be denied, and the file deleted or marked unauthenticated. These time and geographical requirements ensure that the user does not have enough time to modify the image file.
The image authentication application 101 may place additional restrictions to aid in the authentication process. The image authentication 101 may allow images that were taken within the application 101 to be sent to authentication server 110. The image authentication 101 may also restrict the use of editing tools within the image authentication 101. It may also prevent the export of image files to other programs for editing. The image authentication application 101 makes sure that the image file remains within the approved environment for the entire life of the file. It also ensures that the user is not allowed to modify any part of the file, including metadata or images.
“In cases where the above-mentioned restrictions are used, once the image authentication app 101 has verified that the image file meets these restrictions, it can generate a hash from the image file and then send it to the authentication server 110. The image authentication application 101 can send the file if the network connection is improved or another network connection becomes available. Metadata (e.g. time and location data) may be attached to the image file along with the hash and/or image files. The authentication server 110 does various tasks to authenticate an image file. It also stores the hash file along with the identifying information.
“When the user device 120 receives a copy of the image, the authentication server 110 can generate a server generated hash file using the copy and compare it with the user-generated hash. The match between the server generated hash file and user device generated hash may indicate that the image file copy has not been altered or altered since its original creation (since the image authentication software 101 created the hash file for the original). The authentication server 110 can apply a watermark to the image file or provide other indications that it has been authenticated.
“Electronic image device 502 could include an electronic sensor that detects and transmits information necessary to create an image. An example of an electronic imaging device 502 could include, but is not limited to, a charge coupled device (??CCD?) sensor, a complementary metal-oxide-semiconductor (?CMOS?) Sensor, and/or any other device that detects and transmits information to create an image. An image can include a still image (e.g. a photograph), or a video image and/or other types.
“Network device 504 could include a network device that connects to and transmits data over a network such as network 101 (illustrated at FIG. 1). One implementation may include a network connection 504 for each type of network connection. One network device 504 could be used to connect to a mobile data connection (e.g.?3G/4G/5G/etc.). Provided by a wireless service provider. A second network device 504 could be configured to connect via a Wireless Fidelity (?WiFi?) connection using an IEEE 802.XXX or another specification. There are other types of network connections that allow communication with an authentication server 150 over a network. One network device 504 can be used to connect to multiple network connections in some cases.
“Location Device 506 could include a device that detects information to identify the physical (e.g. geographic) location of the device. Location device 506 could include, but is not limited to, a Global Positioning System (GPS)? A sensor device, a WiFi-enabled device (for accessing hotspot information), a network device for obtaining IP addresses-based physical locations, and/or any other type of location device that can produce information to locate the physical location of the device 506 (and the user device 120).
“In an implementation, one or more processors (512) may be programmed using computer program instructions such as those stored on the one or multiple electronic storage devices 514. The one or more processors may be programmed, for example, by a native camera app 516 or an image authentication software 101. Native camera application 516 could be an executable program, which is different from the image authentication app 101. It captures images with electronic imaging device 502. The native camera application 516 stores the image files it creates in an easily accessible location. This could be a camera directory, which can be readable with an image album program. These image files can be accessed from the accessible location and edited. Image authentication application 101 can be configured with its own image storage and capture functionality to help stop such open access.
“In an image authentication application 101 implementation, there may be various instructions, such as a settings manager 522 and an image file generator 524. A hash file generator 526. A network connection analyzer 528. A decision engine 350. The various instructions are used herein to describe an operation. However, they actually program the processors (512 and therefore the user device 120) to execute the operation.
“User-Defined Setting and System Rules That Control Operation of Image Authentication App”
“The settings manager 522 can obtain from a user one or more user-defined settings that will be applied to the operation of image authentication app 350. The settings manager 522 might expose a user interface that allows a user to set the behavior of the image authentication app 350. You can specify, among other things, which network connections should be avoided, which network connections may allow image files to be transferred, what maximum file size an image file may be uploaded, and/or any other settings that you want to control the behavior or image authentication software 350.
The settings can be combined or used in conjunction with each other. A user might specify that images should not be sent via cellular data connections, but that they can be sent using a WiFi connection. A user might specify that images larger than a specified size should not be sent via cellular data connections. You can also specify other types of network connections or the alternative. Sometimes, an option may be set by the user to prevent image files from being transmitted when a network connection is low quality. This is a low quality? These?low quality? or?strong? qualities may be misleading. Quality may be measured using network latency, network error rate, or other metrics. These metrics can be used to determine if they meet certain quality thresholds. (These may be set by the user and/or predefined in the image authentication app 350). The image authentication application 350 can decide whether or not to send an image file depending on the quality of the available network connection. To determine what quality is acceptable, the network metric threshold can be used. network connection and what is a strong? network connection. Not all quality metrics can be used. A combination of quality metrics can be used to create an overall network score. This score may be compared with a network quality threshold. These threshold values can be predefined using a user-defined setting or a system rule (described below).
The settings manager 522 can obtain predefined system rules to control the operation of the image authentication app 350. Predefined system rules can include settings that are identical to the user-definable settings. However, instead of being set manually by the user, predefined system rules could be created by developers or other people who are not end users of the user device 120. In this way, some system rules may offer default settings that correspond to the user-defined settings. Other implementations may not allow any user-defined settings, and only the system rules can be used.
“Capturing and Generating Image Files”
“Using the electronic image device 502, image generator 524 can capture an image and create an image file. Depending on what type of image is captured (e.g. photograph, video, etc.), the file size can be adjusted. Image file generator 524 can encode captured images into image files using the appropriate encoding techniques (e.g. JPEG/PNG/etc. MPEG/NTSC/etc. for photographs Videos, etc. Image file generator 524 can store the image file at a file location on an electronic storage device 114. This is known as hidden file location. This hidden location is not visible to user device 120 but can be accessed by the image authentication app 350. The hidden location could be hidden from the user by using native operating system hidden directory techniques. You may also use other file locations.”
“Generating Hash Files.”
“In certain implementations, the hash generator 526 might generate a hashfile based on an images file. The hash generator 526 might generate a hash from the image file by using a hash function, and then generate the hash files based on that hash. Some implementations may use the hash function to map data from an image file into data with a fixed size. This fixed size (e.g. memory footprint) can be smaller than the size of the image. Depending on the size and content of the image files, the fixed size may be orders of magnitudes smaller than that of the image files. The content of an image file may be used to generate a hash function that is deterministic. If the copy has not been altered, the hash of an image file generated by the hash function will match the hash of its copy. A hash function will make it so that a hash for an image file is different from a hash for a modified copy (and even a hash for another file). The authentication server may use a similar hash function. Some examples of hash functions that could be used are SHA256 and SHA512.
“Assessing Network Characteristics.”
“In an implementation, a network connection analyzer 528 might determine one or more characteristics for an available network connection. An available network connect is one that can be established or detected by one or more network devices 504 (e.g., network connections in which broadcast network information has been detected from an access points associated with the connection, network connections in which communication has been established with an accesspoint associated with the connection, network connections in which initial handshake communication with an access station associated with the connection, etc.). One or more characteristics could include, but are not limited to, the type of available network connectivity, the quality of an existing network connection, and/or any other characteristics that define an available connection.
“Types of Network Connectivity”
“In certain implementations, the network connector analyzer 528 might determine types of network connections. The network connection analyzer 528 might identify the type of network connection that is currently being used to transmit data from or to the user’s device 120 via network 102. The network connection analyzer 528 might determine that a network device 504 is connected to a cell network and is being used to transmit or receive data from the user’s device 120. Similar connections may also be made, such as WiFi connections. If configured, one can obtain the types of network connections from the operating system 120 or from the network device 504 in some cases.
“As we will describe, the decision engine 350 may use the type of available internet connection to determine whether to send a hash of an image file or whether to send the image.
“Quality of Network Connections.”
“In some cases, the network connection analyser 528 can determine the quality of one (or more) available network connections. One or more metrics may be used to assess the quality of a network connection. One or more metrics could include a signal strength indicator (or vice versa), a number dropped packets (or vice versa), a ratio received packets to dropped packets (or both), and/or other network quality metrics that can help to evaluate the quality of an available connection.
The network connection analyzer 528 can determine the signal strength of an existing network connection in some cases. A measurement of the signal strength can be taken from access points, such as a signal transmitted by a cellular basestation, a signal transmitted via WiFi router or another WiFi access point, or a measurement taken from an access station of the signal transmitted by the user device 120 to that access point and/or any other signal measurement.
“In certain instances, the network connectivity analyzer 528 might determine a number dropped packets from information that was exchanged between access points (e.g., a cell network base station, WiFi router, etc.). and user device 120.”
The network connection analyzer 528 might determine if there are dropped packets relative to received packets, and/or a ratio. The network connection analyzer 528 might determine a burst rate or other network transmission metric, which can be used to determine a number of dropped packets relative to received packets.
“In certain instances, the network connectivity analyzer 528 might be able to determine the current throughput of the first available network connection. The throughput can be determined based on information about the network performance exchanged between user device 120 (e.g. using control channels) in some cases. The network connection analyzer 528 can sometimes obtain upload throughput by sending one or more predefined data sets with known sizes to a networked device (such authentication server 150). The network connection analyzer 528 can transmit a predefined list of data to the networked devices and calculate the time it took for that set of data (based on acknowledgement receipts from the networked devices). The size and time of the data set may be used by the network connection analyzer 528 to determine throughput. Alternately, or in addition, the network connection analyser 528 can receive the length of the set of data and/or throughput calculation from the networked devices.
“In some cases, the network connection analyser 528 may obtain the download throughput using the same techniques as the upload throughput. However, instead of measuring the transmission of data from user device 120 to networked, the user 120 and/or networked devices measure the data transmitted from the networked to user device 120. The upload throughput and/or download throughput can be used to guide the decision-making process.
“In some cases, the network connectivity analyzer 528 might obtain the current latency of the first available network connection. The latency can be determined based on information about the network performance between user device 120 (e.g. using control channels) and access point. The network connection analyzer 528 can sometimes obtain latency by sending or receiving predefined data sets with known sizes to a networked device (such authentication server 150). The network connection analyzer 528 can transmit a predetermined set of data to the networked devices and calculate the time it took for that set to reach the device. This is based on acknowledgement receipts from the networked devices. The length of time may be used by the network connection analyzer 528 to determine latency. Alternately, or in addition, the network connection analyser 528 can receive the length and/or latency calculation from the networked devices. Sometimes, the length of time can be used to calculate latency.
“It is important to note that multiple network connections may be available. as described herein. The network connection analyzer 528 can be used in these cases to determine the characteristics of a current network connection being used to transmit data from or to the user device 120 via a network such as network 101.
“Decision Engine”
“In some cases, the decision engine 350 can decide whether to send an image file or a hash of the image file depending on the characteristics of a network connection. The decision engine 350, for example, may get one or more characteristics from network connection analyzer 528 and decide that an image file should be transmitted instead. This is based on one or more characteristics of the current network connection available at the time. The decision engine 350 can periodically acquire characteristics of a network connection after the hash file is transmitted. The decision engine 350 might, for example, determine that the image file can be sent by obtaining characteristics of a network connection at a later time.
“The decision engine 350 may decide that the image file should not be sent the first time, but it can take place in a variety of situations. One example is that network conditions, such as quality, may have changed from the first to the second time. This could be the case where signal strength, successful versus dropped packet ratio, latency and/or other quality indicators have improved above a threshold level, whereas they were lower at the first time. Another example is that a second type or network connection might have been available at the second time, but not at the first. While the first network connection is able to send images files, the second network connection can be used for that purpose. Image files can be sent on a WiFi network, but not on a cell network. While a cellular network connection was available initially, a WiFi connection might have become available later. The system rules and user-defined settings may dictate the logic in some cases.
“In certain instances, system rules and/or user defined settings may specify one or several threshold quality values. Each threshold quality value may correspond to a different type of network quality assessment. As an example, the following could be used to define a threshold quality value: A minimal signal strength indicator value can be used to determine a threshold quality value (below the threshold quality threshold 350 is considered a ‘poor quality?). connection, and above which decision engine 350 considers to be a’strong? connection), a predefined value for dropped packets (above which decision engine 350 considers to be a ‘poor quality? connection, and below which the decision engines 350 consider a’strong? Connection), the ratio of dropped packets to received packets (below which decision engine 350 considers a “poor quality?” connection, and above which decision engine 350 considers to be a’strong? connection), a network latency (below which decision engine 350 considers to be a ‘poor quality? connection, and the decision engine 350 considers it a’strong? connection), a network throughput (below which decision engine 350 considers to be a ‘poor quality? connection, and above which decision engine 350 considers it a’strong? connection and above which the decision engine 350 considers a?strong? connection. Implementations that combine one or more of these factors may have a threshold value predefined to reflect a combination score. The decision engine 350 can determine whether there is a weak or strong connection based on whether the network quality metric (e.g., it is higher or lower depending on the threshold value) differs from the threshold value.
The decision engine 350 can determine whether an image or hash file should go out based on a comparison of the current quality metric with the threshold value. For example, if the file is of poor quality? For network connections, it is possible to send the hash file but not the image file. For?strong?” The image file can be sent to network connections.
“FIG. “FIG.
“In an operation 602, 600 could include receiving a request for one or more electronic images that need to be authenticated. A request could include an electronic address from which the user can obtain one or more electronic photos. A 600 operation may also include the obtaining of a unique identifier for the request. The system can generate the unique identifier or provide it in the request. An operation 606 may involve 600 generating a link that allows you to download an application. The link will contain the unique identifier as well as a location on the network from which the application can be downloaded. A 608 operation 600 could include sending a message containing the link to the electronic address to the user. The link, when selected, causes the user to choose the link to download and install the application. In operation 610, 600 could include receiving an electronic picture from the application. The electronic image was generated at user device by application. An operation 612 may also include 600. This process could be used to authenticate the electronic image. Process 600 in an operation 614 may provide access to the electronic images and indicate the authentication to the requester.
“FIG. 7 illustrates a process 700 to locate, install and open an image authentication app 101 for generating and uploading images for authentication. This is according to an implementation. “In an operation 702, process 700 might include”
“In operation 704, process 700 could include receiving a link to download an image authentication software 101. The link could specify a download location or encode a unique identification. A 700 operation may involve downloading, installing, opening, and closing the image authentication app 101 in response to the user’s selection of the link. A 708 operation may involve generating one or more images with the image authentication app 101. This is independent from the native camera application 516. Process 700 in an operation 710 may involve transmitting the unique identification with the generated images and hash for each image, metadata, or other information to authentication server 110. It is important to realize that authenticated images are useful and beneficial in many applications. For example, inspection companies can use authenticated images to document property inspections or financial companies to help them?know your customer?. To ensure that users are accurate and current images, authenticated images can be requested from documents such as utility bills, dating websites, social media, casting directors, etc. To verify the activities and whereabouts their children are, parents can request authenticated images. Users can request images related to their experiences. They can also view images of friends with complete faith that they are accurate representations of their activities. You can track your package and get location information from delivery services. Customers making online purchases or reservations can request and verify the condition of the item they are purchasing or the item/property/vehicle they are renting. Information about the source images can be requested by news outlets. Witnesses can provide reliable and verifiable photos taken on the scene of a crime or accident upon request. These are just a few examples of the many uses for authenticated images.
“FIG. “FIG. 8” shows a screen shot of a landing page interface 800 from the interface portal 216, as provided by the system in accordance with an implementation of the invention. Like reference signs are used to refer to the same component in each interface (e.g. 800-1100). The interfaces 800-1100 are merely for illustration purposes. Many interface components can be modified, added or removed as needed. After logging in, an administrator of an entity wishing to get authenticated images from its customers may display the landing page interface 800 via interface portal 216. The landing page interface 800 could be used to present photos of damage to insured property to an insurance adjuster.
“The landing page interface 800 could include a white-label 801 which provides graphics and/or texts to give a look and feel of the entity, a search output 803, a new inspection hyperlink 810, a ready-to-review link 820, an inspection workflow URL 830, and/or any other interface components. Display options may be available for searching the computer system 104 using search terms. Search terms could include search terms for users, such as insured users and/or any other terms.
“The landing page interface 800 could include links to other pages. The New Inspection link 810 may display an image request interface, for example. FIG. 9. When you select the Ready to Review link 820 it may display a list of inspections that have images uploaded by users. An inspection view interface can be displayed after selecting an inspection. FIG. 10. When you select the All Open Inspections link 830 it may display an inspection listing interface. FIG. 11. When you select the Recently Viewed link, 840, a list of recent image requests may be displayed.
“FIG. “FIG. 9” shows a screen shot of an image request interface (900) of the interface portal 216, as provided by the system in accordance with an implementation of the invention. Image request interface 900 can include input options to receive parameters from users in order to request authentication images. The image request interface 901 may contain a name input 901 to receive a name from which to request images. An electronic address input 903 is used to send a link to an image authentication app 101 to the user. A user ID input 905 can be used to input an identifier, such as a claim number, or any other identifier. A note input 107 allows for the receipt of a note that will be delivered to the recipient. Finally, a send input 909 sends the request to user. A message preview 911 may be available on the image request interface 900. This preview shows how the message will look to the recipient.
“FIG. “FIG. 10” shows a screen shot of an inspection interface 1000 of the portal 216. This interface is provided by the system according to an implementation. An inspection view interface 1000 could include a portion 1003, which allows users to upload images and provide information about the inspection. An inspection view interface 1000 could include a location panel 1010, status pane 1020 and images pane 10030.
“The location pane 1010 can include a visual and/or textual indication of a place from which images were taken or transmitted by the user via image authentication 101. Examples (as shown) display a message that indicates the location is not available if an image hasn’t been uploaded yet. The location pane 1010 may display the image’s location. Multiple images may be uploaded. The location of each image can change when it is viewed at the images pages 1030.
“The status pane 1020 can include information about the status of the inspection, such as images authenticated, images awaiting images, images failed authentication, reasons for failure, and so on. A status pane 1020 could include an event log 1014 which lists all events related to the inspection. The event log could start with the initial request by the user for images. It may also track any subsequent activity since that request.
Click here to view the patent on Google Patents.How to Search for Patents
A patent search is the first step to getting your patent. You can do a google patent search or do a USPTO search. Patent-pending is the term for the product that has been covered by the patent application. You can search the public pair to find the patent application. After the patent office approves your application, you will be able to do a patent number look to locate the patent issued. Your product is now patentable. You can also use the USPTO search engine. See below for details. You can get help from a patent lawyer. Patents in the United States are granted by the US trademark and patent office or the United States Patent and Trademark office. This office also reviews trademark applications.
Are you interested in similar patents? These are the steps to follow:
1. Brainstorm terms to describe your invention, based on its purpose, composition, or use.
Write down a brief, but precise description of the invention. Don’t use generic terms such as “device”, “process,” or “system”. Consider synonyms for the terms you chose initially. Next, take note of important technical terms as well as keywords.
Use the questions below to help you identify keywords or concepts.
- What is the purpose of the invention Is it a utilitarian device or an ornamental design?
- Is invention a way to create something or perform a function? Is it a product?
- What is the composition and function of the invention? What is the physical composition of the invention?
- What’s the purpose of the invention
- What are the technical terms and keywords used to describe an invention’s nature? A technical dictionary can help you locate the right terms.
2. These terms will allow you to search for relevant Cooperative Patent Classifications at Classification Search Tool. If you are unable to find the right classification for your invention, scan through the classification’s class Schemas (class schedules) and try again. If you don’t get any results from the Classification Text Search, you might consider substituting your words to describe your invention with synonyms.
3. Check the CPC Classification Definition for confirmation of the CPC classification you found. If the selected classification title has a blue box with a “D” at its left, the hyperlink will take you to a CPC classification description. CPC classification definitions will help you determine the applicable classification’s scope so that you can choose the most relevant. These definitions may also include search tips or other suggestions that could be helpful for further research.
4. The Patents Full-Text Database and the Image Database allow you to retrieve patent documents that include the CPC classification. By focusing on the abstracts and representative drawings, you can narrow down your search for the most relevant patent publications.
5. This selection of patent publications is the best to look at for any similarities to your invention. Pay attention to the claims and specification. Refer to the applicant and patent examiner for additional patents.
6. You can retrieve published patent applications that match the CPC classification you chose in Step 3. You can also use the same search strategy that you used in Step 4 to narrow your search results to only the most relevant patent applications by reviewing the abstracts and representative drawings for each page. Next, examine all published patent applications carefully, paying special attention to the claims, and other drawings.
7. You can search for additional US patent publications by keyword searching in AppFT or PatFT databases, as well as classification searching of patents not from the United States per below. Also, you can use web search engines to search non-patent literature disclosures about inventions. Here are some examples:
- Add keywords to your search. Keyword searches may turn up documents that are not well-categorized or have missed classifications during Step 2. For example, US patent examiners often supplement their classification searches with keyword searches. Think about the use of technical engineering terminology rather than everyday words.
- Search for foreign patents using the CPC classification. Then, re-run the search using international patent office search engines such as Espacenet, the European Patent Office’s worldwide patent publication database of over 130 million patent publications. Other national databases include:
- European Patent Office (EPO) provides esp@cenet to access a network of Europe’s patent databases with access to machine translation of European patents.
- Japan Patent Office (JPO) – with access to machine translations of Japanese patents.
- World Intellectual Property Organization (WIPO) offers PATENTSCOPE with a full-text search of published international patent applications and machine translations for some documents, as well as a list of international patent databases.
- Korean Intellectual Property Rights Information Service (KIPRIS)
- State Intellectual Property Office (SIPO) with machine translation of Chinese patents.
- Other International Intellectual Property Offices with online patent databases include Australia, Canada, Denmark, Finland, France, Germany, Great Britain, India, Israel, Netherlands, Norway, Sweden, Switzerland, and Taiwan.
- Search non-patent literature. Inventions can be made public in many non-patent publications. It is recommended that you search journals, books, websites, technical catalogs, conference proceedings, and other print and electronic publications.
To review your search, you can hire a registered patent attorney to assist. A preliminary search will help one better prepare to talk about their invention and other related inventions with a professional patent attorney. In addition, the attorney will not spend too much time or money on patenting basics.
Download patent guide file – Click here