US9430578B2 - System and method for anchoring third party metadata in a document - Google Patents

Abstract

Systems and methods disclosed herein relate to a method of storing metadata for a file on a cloud based storage system. A server may receive a request from a third party application to store metadata for a file. The server may determine a metadata type based on the request. The server may associate the metadata value with an application identifier. The application identifier may identify a third party application. The server may store the metadata value based on the determined metadata type. The stored metadata may be associated with the application identifier and the stored metadata value may include information related to an anchor. The anchor may be an attribute of the file, and anchor can change respectively as the attribute changes.

Description

FIELD OF THE DISCLOSURE

This disclosure relates to systems and methods for third party anchoring of metadata in a document. More particularly, this disclosure relates to providing an interface for third party applications to interact with the metadata associated with files stored on a cloud based storage system.

BACKGROUND

Cloud based storage systems allow users to store files on a network based storage system. Some cloud based storage systems include cloud based applications for the users to access the files on the cloud based storage system using a web based client application. By using the cloud based application, a user may also be able to annotate parts of the file with metadata. For example, a user may wish to mark some text in the file as important by selecting a portion of the document and marking it using a comment feature. The corresponding metadata for the comment is often associated with a proprietary document model. Therefore, access to the metadata may be limited to cloud based applications or native applications designed with knowledge of the proprietary document model.

Sometimes native applications or cloud based applications may not be capable of accessing and modifying all types of file formats. In some cases, the user may need to process the file using an application that serves a very specific functional need. Therefore, there may be a need for accessing the files using third party applications. Third party applications may not understand the document model of cloud based storage files. Therefore, the user may lose information related to the file while trying to access the file using a third party application. To prevent third party applications from losing metadata information, there is a need for exposing the metadata related to content of the document.

SUMMARY

Accordingly, systems and methods disclosed herein provide third party applications with access to the metadata related to content of a file stored on a cloud based storage device.

Certain implementations relate to a method of storing metadata for a file on a cloud based storage system. A server may receive a request from a third party application to store metadata for a file. The server may determine a metadata type based on the request. The server may associate the metadata value with an application identifier. The application identifier may identify a third party application. The server may store the metadata value based on the determined metadata type. The stored metadata may be associated with the application identifier and the stored metadata value may include information related to an anchor.

Certain implementations relate to systems for storing metadata for a file on a cloud based storage system. The system may comprise a server that is configured to communicate over a network with a client system. The server may receive a request from a third party application to store metadata for a file. The server may determine a metadata type based on the request. The server may associate the metadata value with an application identifier. The application identifier may identify a third party application. The server may store the metadata value based on the determined metadata type. The stored metadata may be associated with the application identifier and the stored metadata value may include information related to an anchor.

BRIEF DESCRIPTION OF THE DRAWINGS

Further features of the disclosure, its nature and various advantages will be apparent upon consideration of the following detailed description, taken in conjunction with the accompanying drawings, in which like reference characters refer to like parts throughout, and in which:

FIG. 1 is a block diagram of multiple systems communicating through a network in accordance with an implementation of the disclosure, according to an illustrative embodiment;

FIG. 2 is a diagram of an example of a display of a text file and corresponding metadata on a client system, according to an illustrative embodiment;

FIG. 3 is a diagram of an example of a display of a text file and corresponding metadata on a client system, according to an illustrative embodiment;

FIG. 4 is a diagram of an example of a display of an image file and corresponding metadata on a client system, according to an illustrative embodiment;

FIG. 5 is a diagram of an example of a display of an image file and corresponding metadata on a client system, according to an illustrative embodiment;

FIG. 6 is a diagram of an example of a display of an image file and corresponding metadata on a client system, according to an illustrative embodiment;

FIG. 7 is a diagram of an example of a display of an image file and corresponding metadata on a client system, according to an illustrative embodiment;

FIG. 8 is a diagram of an example of a display of an image file and a corresponding metadata associated with the image file on a client system, according to an illustrative embodiment;

FIG. 9 is a diagram of an example of a display of a spreadsheet file and corresponding metadata associated with the spreadsheet file on a client system, according to an illustrative embodiment;

FIG. 10 is a diagram of an example of a display of a file browser for a cloud based storage application, according to an illustrative embodiment;

FIG. 11 is an example of a data structure of metadata stored in relation to a file on a cloud based storage system, according to an illustrative embodiment;

FIG. 12 is a flowchart of a method used by a computerized system for storing metadata received from a third party application, according to an illustrative embodiment;

FIG. 13 is a flowchart of a method used by a computerized system for associating metadata received from a third party application with file revision information, according to an illustrative embodiment; and

FIG. 14 is a flowchart of a method used by a computerized system for transmitting metadata to a third party application, according to an illustrative embodiment; and

FIG. 15 is a block diagram of a computing device, such as any of the components of the system ofFIG. 1, for performing any of the processes described herein, according to an illustrative embodiment.

DETAILED DESCRIPTION

To provide an overall understanding of the systems and methods described herein, certain illustrative examples will now be described, including a system for storing metadata received from a third party application. However, it will be understood that the systems and methods described herein may be adapted and modified as is appropriate for the application being addressed and that the systems and methods described herein may be employed in other suitable applications, and that such other additions and modifications will not depart from the scope thereof.

The present disclosure provides systems and methods for exposing metadata associated with the content of files stored on a cloud based storage system. Interfaces between shared files in cloud based storage systems and third party applications are not well established. The systems and methods disclosed herein provide third party applications with an interface to access metadata related to files stored on a cloud based storage device. In particular, the present disclosure relates to providing, to a third party application, the ability to create and store metadata related to content of files stored on a cloud based storage system.

Data stored on a cloud based storage system may be received by a client system for processing, for example, using a locally installed application on the client system. For example, a text document may be downloaded to a client system and opened with a locally installed document processing application. A web based application that can be accessed online by a user rather than installed locally on a local client system, can also be used to process the text document. These online applications, which may have the same features and functionality as locally installed applications, are typically hosted on a remote server rather than a local client system, which allows the user to access the online applications from any device having internet access. Online applications may be capable of opening and processing data files stored on the cloud based storage system.

The present disclosure provides techniques for interfacing between third party applications, server systems that host online applications, and cloud based storage systems that store data files. In an example implementation, a client system may request, via a third party application, to open and process a data file stored on a cloud based storage system using an online application. The third party application may send a request to access a file to a server that interfaces with the cloud based storage system and the online applications. The request may include file information, which identifies a data file stored on the cloud based storage system, and also identification information of the user. The server may then process the request and provide to the client system the data file. The data file may include metadata associated with the content of the data file.

The metadata associated with the content of the data file may be anchored to one or more positions within the document. The data type for the anchor positions for the metadata may vary based on a file format of the data file. For example, when the data file is a photograph, the anchor position may be a pixel location of the metadata within the photograph. The client system may in turn provide the user with an interface to annotate the copy of the data file with metadata. The interface may be a browser interface, a mobile interface, an application graphical user interface, and/or other suitable interface for interacting with the copy of the data file. The user may use the interface to create metadata and anchor it to the content of the data file. The third party may transmit the metadata and the corresponding anchors to the server. The server may store the metadata received from the client and associate it with a respective document model of the file.

An exemplary system for implementing an interface between a client system, cloud based storage system and an online application system is shown inFIG. 1.FIG. 1 depicts an example of a network and network systems that may be used to implement the systems and methods described herein.FIG. 1 is a block diagram of asystem100 for athird party application118 to access metadata related to content of files stored on a cloud basedstorage system104. Thesystem100 includes aclient system114, aserver system106, a cloud basedstorage system104, and/or athird party system124. Each network system may include control circuitry configured to control the operation of the respective system. Processes and operations performed by each system may be implemented using the control circuitry. Only one cloud basedstorage system104, oneclient system114, oneserver106, and onethird party system124 are shown inFIG. 1 to avoid complicating the drawing. In general, thesystem100 can support multiple cloud basedstorage systems104,client systems114,servers106, andthird party systems124.

The cloud basedstorage system104 is a file hosting system that allows users to store and retrieve data accessible to one or more client systems such as theclient system114. This data may be referred to as a user file. As an example, the cloud basedstorage system104 may store data on a single server system or in a distributed system. As used herein, the terms “user file” or “shared file” refer to data files stored on cloud basedstorage system104, and may be used interchangeably. User files and shared files may be associated with a particular user. Shared files may also include files shared by other users. Examples of user files may be text documents, spreadsheets, multimedia files, and other types of binary data. Each user file may also have metadata associated with the user file. This metadata may be stored on the cloud basedstorage system104 in ametadata database110. The metadata may also be stored within the user file itself. Metadata includes information about the user file. Examples of metadata include filenames, dates and times that the file may have been accessed or processed, security information, generated previews of the file, and any other types of information related to the user file. In some implementations metadata may also be content related metadata. Examples of content related metadata may include comments by users on a selection of a file, tags identifying a user in an image file, tags identifying an author of a specific portion of a file, a thumbnail of the content of the file, and/or other suitable data related to the content of the file.

Server106 may receive requests for user files fromclient systems114 and fromthird party systems124 overnetwork102. In response to the requests, theserver106 accesses user files stored on the cloud basedstorage system104. Theserver106 inFIG. 1 is shown as a part of the cloud basedstorage system104. It is understood thatserver106 may be implemented on a separate computing system from the cloud basedstorage system104. Theserver106 includes a processor which may be configured to perform the processes and operations ofserver106. The requests fromclient systems114 may include requests to access content related metadata of the user files.Server106 may access themetadata database110 to grant theclient systems114 requests. In some implementations, the request may be received from anative application116 running on theclient114. Thenative application116 may be an application that fully understands an internal data model of the user file. Theserver106 may access thenative database108 in order to service the requests from thenative application116. The request may be sent via athird party application118 running on theclient system114 and/or athird party system124. Theserver106 may access themetadata database110 to service the request received via thethird party application118.

Aclient system114 may send a request for accessing content related metadata to theserver106. Theclient system114 may use anative application116 to interface with the server. In some implementations, thenative application116 may be a web based browser application. Thenative application116 may interface with thenative database108 via an online application executing on the server. The online application may have access to the data model of the user file and may service theclient systems114 request to access the content related metadata by accessing thenative database108. Thenative database108 may store content related metadata by mapping them to identifiers in memory. An identifier may include alphanumeric characters, and/or other suitable ways to provide a unique identification for the content related metadata. A mapping of the identifier to the metadata may be stored in thenative database108.

In some implementations, theclient system114 may use athird party application118 as an interface with the server. Thethird party application118 may be a document processing application, an image processing application, a spreadsheet application, and/or any other suitable application for interfacing with the user file. Thethird party application118 may request theserver106 to access content related metadata. Thethird party application118 may not have knowledge of an internal data model. In an illustrative example, the request may be a request to store content related metadata and may include metadata and one or more associated anchor positions of the metadata. Theserver106 may service the request from thethird party application118 using themetadata database110. The server may associate content related metadata with one or more anchors for the metadata. The anchors may contain information related to the location of the content related to the metadata within the user file.

In certain implementations, athird party system124 may send a request for accessing content related metadata to theserver106. Thethird party system124 may be a server system for a third party cloud based application. For example, thethird party system124 could be a server for a web based service for aggregating media files for the user from cloud based storage systems used by the user. Theserver106 of the cloud basedstorage system104 may service the request from thethird party system124 using themetadata database110.

FIG. 2 is a diagram of an example of adisplay200 of a text file and corresponding metadata on a client system similar to theclient system114 ofFIG. 1. It is to be understood that whileFIG. 2 illustrates a user file as atext file202, concepts discussed with respect toFIG. 2 may be applied to other user file formats. Some examples of other user file formats may include spreadsheets, presentations, videos, pdfs, images, and/or other suitable formats. It is understood that the other file formats may apply to other examples discussed in the disclosure and are not limited to the concepts discussed inFIG. 2. Thedisplay200, as illustrated byFIG. 2, is an example of an interface of a third party application and/or a native application similar to thethird party application118 and/or thenative application116 ofFIG. 1 respectively. A user may use an input device to select ananchor206 within thetext document202. The user may associate a metadata with theanchor206. In an example implementation, the metadata may include acomment204. It is understood that while the metadata illustrated inFIG. 2 is a comment, concepts discussed herein apply to other types of metadata and may apply to other examples of the disclosure. Examples of other types of metadata may include the name of the author of a portion of the document, a username of a person included in a picture, and/or other suitable data related to the content of a document. Theanchor206 within thetext document202 may comprise information related to the position of theanchor206 within the document. For example, theanchor206 may comprise a byte offset of a word within thetext document202.

In some implementations, the location of theanchor206 is adjusted with changes made to the text document. In the illustration ofFIG. 2, theanchor206 includes the selection of the word “light” and corresponding metadata is thecomment204. As the text document changes, thecomment204 location changes with a corresponding change in location of the word “light” within the text document.FIG. 3 will illustrate the movement of the anchor with respect to changes made to the document.

FIG. 3 is a diagram of an example of adisplay300 of atext document302 and corresponding metadata on a client system. Thedisplay300 corresponds to thedisplay200 ofFIG. 2. Thetext document302 corresponds to thetext document202 ofFIG. 2. Ananchor306 corresponds to theanchor206 ofFIG. 2. Acomment304 corresponds to thecomment204 ofFIG. 2. Thetext document302 is a modified version of thetext document202. Thetext document302 has additional text in comparison to thetext document202. The movement of theanchor206 to theanchor306 illustrates that the location of theanchor306 may change as changes are made to thetext document302. In some implementations, when a user adds data to thetext document302, the location of theanchor306 within the document may also change. Accordingly, if data is added before theanchor306, then a position of theanchor306 is adjusted according to the modification. Likewise, if data is added after theanchor306, the position of theanchor306 remains unchanged.

FIG. 4 is a diagram of an example of adisplay400 of animage file402 and corresponding metadata on a client system. Thedisplay400, as illustrated byFIG. 4, is an example of an interface of a third party application and/or a native application similar to thethird party application118 and/or thenative application116 ofFIG. 1 respectively. A user may use an input device to select ananchor406 within theimage file402. The user may associate a metadata with theanchor406. In an example, the metadata may include acomment404. Theanchor406 within theimage file402 may comprise information related to the position of theanchor406 within theimage file402. For example, ananchor406 may include a rectangle with information identifying the pixel location of any one of the corners of the rectangle and/or the width and height of the rectangle. It is understood that while theanchor406 illustrated byFIG. 4 is a rectangle, an anchor may be circular, triangular, and or other suitable forms for representing a portion of an image file. In some implementations, the location of theanchor406 is adjusted with changes made to theimage file402. In the illustration inFIG. 4, theanchor406 includes a rectangular selection of the image. The illustratedanchor406 corresponds to thecomment404 which may have been associated with the anchor by a user of theimage file402. The location of theanchor406 may adjust accordingly as changes are made to theimage file402.

FIG. 5 is a diagram of an example of adisplay500 of animage file502 and corresponding metadata on a client system. Thedisplay500 corresponds to thedisplay400 ofFIG. 4. Theimage file502 corresponds to theimage file402 ofFIG. 4.Anchor506 corresponds to theanchor406 ofFIG. 4.Comment504 corresponds to thecomment404 ofFIG. 4. Theimage file502, as illustrated herein, is a modified version of theimage file402.FIG. 4 illustrates that theimage file502 has been scaled up in comparison to theimage file402 ofFIG. 4. Accordingly, the boundaries defining therectangular anchor506 are also scaled up to adjust for the changes made to theimage file502.

In some implementations, the metadata may include revision information of the image. The revision information may help in preventing stale metadata. Stale metadata may be, for example, anchored to a portion of a file that has been removed, deleted, and or replaced.FIGS. 6-7 illustrate a scenario in which an image file may include stale metadata.

FIG. 6 is a diagram of an example of adisplay600 of animage file602 and corresponding metadata on a client system.FIG. 7 is a diagram of an example of adisplay700 of animage file702 and corresponding metadata on a client system. Theimage file702, in an illustrative example, is a modified version of theimage file602. In an illustrative example, the user selects arectangle anchor606 and adds acomment604 metadata to theanchor606. After adding the metadata to the file, the user may replace theimage file602 with anew image file702. In some implementations, thecomment604 is associated with a revision number. Thecomment604 may be displayed if the revision number of the content matches the revision number of the metadata. When the user replaces theimage file602, the revision number of the user file is updated. However, the revision number of the metadata remains the same. A server system similar to theserver106 ofFIG. 1 may detect the mismatch between the metadata revision number and file revision number and prevents the third party application from displaying stale metadata.

FIG. 8 is a diagram of an example of adisplay800 of animage file802 and corresponding metadata on a client system. The image file, according to an illustrative example, includes twoanchors806 and808. Metadata corresponding to the anchors is acomment804 made by a user. A data structure namedApp1.AnchorSquare816 corresponds to thesquare anchor806. The datastructure App1.AnchorSquare816 is an example of a format for storing an anchor position in the metadata database of a cloud based storage system similar to the cloud basedstorage system104 ofFIG. 1. The App1.AnchorSquare data structure816 may include attributes such as revision_no., type, x_axis_location, y_axis_location, width, height and/or other suitable data for storing information about the anchor's location. A user may add additional attributes to the data structure. The revision_no. attribute corresponds to a state of the user file at the time the metadata is created. The type attribute may correspond to a graphical element that a user may select in order to anchor the metadata. For example, the user may select a geometrical object within a file as an anchor. The selected geometrical object may define the type attribute of the anchor. For example, the selected geometrical object may be a rectangle, circle, triangle, and other suitable geometries. In an illustrative example, the user may select a frame of a video file corresponding to a point in time. The type attribute corresponding to the selected frame of the video may be defined by the selection of the point in time. The type of data structure corresponding to the point in time may be time based. The time data structure may include other attributes such as seconds, minutes, hours, and/or other suitable units of time. An App1.AnchorCircle data structure818 corresponds to thecircular anchor808. The App1.AnchorCircle data structure818 is an example of a format for storing anchor data corresponding to a circle in the metadata database. In some implementations, the circle data structure may store attributes related to the geometry of thecircular anchor808. Some examples of the attributes of thecircular anchor808 geometry include location of the center of the circle in x_axis_location and y_axis_location, radius of the circular geometry, and/or other suitable data related to defining an anchor within a document.

FIG. 9 is a diagram of an example of adisplay900 of a spreadsheet file902 and corresponding metadata associated on a client system. The spreadsheet file902 includes acell anchor906. The metadata corresponding to thecell anchor906 is acomment904 made by a user Mark. A datastructure App1.SpreadSheetCell916 corresponds to thecell anchor906. The datastructure App1.SpreadSheetCell916 is an example of a format for storing thecell anchor906 in the metadata database of a cloud based storage system similar to the cloud basedstorage system104 ofFIG. 1. The datastructure App1.SpreadSheetCell916 may include attributes such as revision_no., type, row, col, sheet, num_rows, num_cols and/or other suitable data for storing information about the cell anchor's906 location. A user may add additional attributes to the datastructure App1.SpreadSheetCell916. The revision_no. attribute corresponds to a state of the spreadsheet file902 at the time the metadata is created. The type attribute may correspond to a location element within the spreadsheet file that a user may select in order to anchor the metadata. For example, the user may select an element of content making up the file. For example, in the illustrative example ofFIG. 9, a user may select at least one cell of the spreadsheet file. The selected at least one cell of the spreadsheet file may be a spreadsheet_cells anchor type. It is understood that the type of anchor as spreadsheet_cells is an example of the type of an anchor and that the type of the anchor may refer to other suitable types for defining the type of content selected to anchor the metadata. In the example of a spreadsheet_cells type anchor, the row attribute may correspond to a row location of the selected spreadsheet cell within the file. The row location of a cell refers to the number of consecutive cells above the selected cell. The col location of a cell refers to the number of consecutive cells to the left of the selected cell. A spreadsheet file may have multiple sheets of data. The sheet attribute may correspond to an identifier of a sheet containing the anchor of the metadata. In an example, where the anchor corresponds to multiple cells in the spreadsheet, the num_rows and num_cols attributes may capture the width in number of cells and the height in number of cells, respectively, of the range of the multiple cells.

FIG. 10 is a diagram1000 of an example of adisplay1000 of afile browser1002 for a cloud based storage application. Thefile browser1002 may be a web based application for viewing files stored on a cloud based storage application similar to the cloud basedstorage system104 ofFIG. 1. Athumbnail1006 may be associated with eachfile1004 on the cloud based storage system. Thethumbnail1006 may be a compressed snapshot of the content of the file. As illustrated indisplay1000, thethumbnail1006 provides the user with a compressed view of the content of the file. Thethumbnail1006 may be included with the metadata for the file. The metadata corresponding to thethumbnail1006 may be stored in adata structure1008 on a metadata database. The data structure may include attributes such as type, file identifier, file location, revision, thumbnail, and thumbnail_app. A type attribute may include information about a third party application used to create thethumbnail1006. The file identifier attribute may include information for identifying the corresponding file on the cloud based storage system. The file location attribute may include information for locating a parent folder of the file on the cloud based storage system. The revision number attribute may correspond to a version of the file at the time thethumbnail1006 is created. The thumbnail attribute may include information for locating a parent folder of the thumbnail on the cloud based storage system. In some implementations, the thumbnail_app identifies a third party application used for creating the thumbnail associated with a cloud based storage file. It is understood that the data structure described herein in is for illustrative purposes. The data structure may be modified and adapted accordingly for supporting the systems and methods disclosed herein.

FIG. 11 is a diagram of an example of adata structure1100 of metadata of a file on a cloud based storage system similar to the cloud basedstorage system104 ofFIG. 1. The metadata may be related to the entire content of the file. The metadata related to the entire content of the file may be stored in aFileInfo data structure1102. TheFileInfo data structure1102 may include attributes relevant to the entirety of the file. For example, a type attribute may define the format of the file and the nature of the content of the file. For example, a file containing graphical data may have a corresponding image attribute type. Likewise, a file containing comma delimited text may be classified as a spreadsheet file type. It is understood that theFileInfo data structure1102 may include attributes related to the file. Some examples of the file related attributes may include but are not limited to file identifier, file location, revision, transformation, thumbnail related information, comments related to the file and/or other suitable attributes relevant to the file.

In some implementations, metadata may be related to content of the file. In an example implementation, the cloud based storage system may store the metadata related to the content of the file in two parts. One part may include the content of the metadata. For example, a comment related to a selected portion of the file may have a corresponding data structure for storing the comment.Data structure1100 illustrates an App1.comment data structure1104 for storing the content of a comment. It is understood that whiledata structure1104 illustrates a two part name separated by a “.” between application identifier “App1” and metadata type “comment”, the metadata may not be associated with any particular application. The comment metadata as illustrated in this case may be stored as a “.comment”, “comment”, and/or other suitable namespace format for storing an application agnostic metadata. The comment data structure may store attributes such as type, revision, date, comment identifier, file ID, author, content, anchors, and/or other suitable data for representing the comment. The anchors attribute of the comment data structure may link to ananchor data structure1106 using an anchor naming convention.

It is possible that a first application may request the server for creating, modifying and/or reading a metadata type associated with a second application. The request from the first application may, in this case, include an application identifier associated with the second application. The server may retrieve metadata associated with the second application in order to service the request from the first application. In some implementations, the naming scheme of the metadata may be used for implementing access control for third party application metadata. For example, it may be possible to limit a first application App1 to only access metadata with “App1” and/or null as an application identifier. In certain cases, third party applications may choose to grant other third party applications rights to create, modify, and/or read their associated metadata values. It is understood that concepts discussed herein of the naming scheme for metadata may also apply to a naming scheme of anchors.

The second part of the data structure may include information about the location of content of the file to which the metadata may be related. In an example implementation, theanchor data structure1106 may store a list of anchors in a file. In theillustrative data structure1100, the anchor data structure includes a list of two anchors. In some implementations, individual anchors for a file may be identified by a two-part name form separated by a “.” in the middle. For example the App1.AnchorA name has an “App1” part and an “AnchorA” part. The anchor naming scheme used in theanchor data structure1106 may be used for identifying an anchor. The first part, App1, in the illustration of the anchor naming convention may correspond to an identifier of a third party application used to create the anchor. If the anchor is associated with a third party application identifier, the third party application may define rules for interpreting the anchor with respect to the content of the file. In some implementations, the anchor may not be related to a third party application, and the “App1” part may be null. For example, a native “AnchorA” may be stored as “AnchorA”, “.AnchorA”, and/or other suitable ways for storing application agnostic anchors. The second part may refer a type for identifying the anchor. The two part form for naming the anchor may reduce collisions between naming schemes for similar anchors used by a different third party application. Thecomment data structure1104 may link to theanchor data structure1106 using the two-part name of the anchor as an identifier.

FIG. 12 is a flowchart of amethod1200 used by a computerized system for storing metadata received from a third party application. Atstep1210 ofmethod1200, a server system similar to theserver system106 ofFIG. 1 may receive a request from a third party application to create metadata related to the content of a file stored on a cloud based storage system. The request may include, among other data, a file identifier for identifying the file, a link to a location of the file on the cloud based storage system, a revision number corresponding to a version of the file, a transformation matrix corresponding to a coordinate system of the third party application, an application identifier for identifying the third party application, a metadata type for identifying the nature of metadata to be created, a corresponding metadata value of the metadata, anchor positions related to the metadata and/or other suitable information related to creating metadata related to the file and/or content of the file. The metadata value may be similar to themetadata data structure1104 ofFIG. 11. The anchor positions may be similar to anchor positions indata structure1106 ofFIG. 11. The server may extract the information from the request to determine a metadata type.

Atstep1214, the server may determine the metadata type received in the request. The server system may use the third party application identifier and/or the metadata type to determine a corresponding metadata type. In response to determining that metadata database does not have a corresponding metadata type, the server may create an entry for the new metadata type in the metadata database. The server may execute validation steps to determine whether data for storing the metadata in the metadata database is included in the request meets a certain standard. In response to determining that the data for storing the metadata is not included in the request, the server may transmit an error message to the third party application. In response to determining that the data for storing the metadata is not included in the request, the server may store metadata as file related metadata.

Atstep1218, the server may store the metadata in the metadata database. The server may store the metadata values in a data structure similar to thecomment data structure1104 ofFIG. 11 and the server may associate a metadata identifier with the stored metadata. The metadata may correspond to a comment. Accordingly, the server system may extract the metadata type and a metadata value from the request to create a comment data structure similar to thecomment data structure1104 ofFIG. 11. The server system may extract anchor positions from the metadata value to identify any anchor positions contained in the metadata value. The extraction of the anchor positions may be achieved using a serialization scheme. In some implementations, the serialization scheme may be a publicly available serialization scheme such as JSON, a proprietary serialization scheme, and/or other suitable serialization scheme. The anchor positions may be stored on a metadata database in a data structure similar to theanchor data structure1106.

FIG. 13 is a flowchart of amethod1300 used by a computerized system for associating metadata received from a third party application with file revision information. Atstep1310, the server system receives a request from a third party application to store metadata.Step1310 may be similar to step1210 ofFIG. 12. Atstep1314, the server system may extract revision information of the file from the request received instep1310. In some implementations, the request may not include the revision information and/or the revision information may be null. The server system may determine from the request received instep1310 that the revision information is not available.

Atstep1318, in response to determining that the revision information is not available, the server may associate current revision information with the metadata information. The current revision information may correspond to a most recent state of the file on the cloud based storage system. In associating the current revision information with the metadata, the server may store the revision information in data structures similar todata structures1104 and1106 ofFIG. 11.

FIG. 14 is a flowchart of amethod1400 used by a computerized system for transmitting metadata to a third party application. Atstep1410, the server may store metadata corresponding to a metadata type.Step1410 may correspond to step1318 ofFIG. 13.

Atstep1414, the server may receive a request from a third party application to read metadata related to a file and/or metadata related to content included in the file. The request may include information for identifying the metadata content of the file. For example, the request may include a file identifier for identifying the file, an application identifier for identifying a part of the metadata name, a metadata type for identifying the nature of the metadata requested, a metadata identifier for identifying a specific metadata and/or other suitable data for identifying the metadata requested by the third party application. In some implementations, the server may use the application identifier and the metadata type to find data structures similar todata structures1104 and1106 ofFIG. 1. The metadata requested may also be metadata created by the native application in conjunction with the server, in which case, the server may use the metadata type to find relevant data structures. The server may retrieve metadata corresponding to the application identifier, the metadata type, and/or metadata identifier to service the request. In another example implementation, the server may retrieve metadata associated with file identifier to service the request.

The server may optionally implementsteps1418 and1422. Atstep1418, the server may determine file revision information. The server may access file related metadata data structure similar todata structure1102 ofFIG. 11 to access a revision number corresponding to a current state of the file.

Atstep1422, the server may determine a metadata revision number. The server may access a metadata data structure similar todata structures1104 and1106 ofFIG. 11. The server may access a revision number attribute of the metadata data structure to determine the metadata revision number. In some implementations the metadata revision number may include, among other information, the revision number attribute of the data structure. The server may compare the metadata revision number to the file revision information determined instep1418. In response to determining that the metadata revision number is similar to the file revision number, the server may proceed withstep1426 ofmethod1400. In response to determining that the metadata revision number is different from the file revision number, the server may determine whether the content related to metadata may have changed since the creation of the metadata. In response to determining that the content related to the metadata may have changed, the server may not transmit the corresponding metadata to the third party application. In response to determining that the content related to the metadata is similar to content related to the metadata at the time of creation of the metadata, the server may proceed withstep1426 ofmethod1400.

Atstep1426, the server may transmit the retrieved metadata and/or anchor positions associated with the metadata to the user.

FIG. 15 is a block diagram of a computing device, such as any of the components of the system ofFIG. 1, for performing any of the processes described herein. Each of the components of these systems may be implemented on one ormore computing devices1500. In some aspects, a plurality of the components of these systems may be included within onecomputing device1500. In some implementations, a component and a storage device may be implemented acrossseveral computing devices1500.

Thecomputing device1500 comprises at least onecommunications interface unit1508, an input/output controller1510,system memory1505, and one or moredata storage devices1515. The system memory includes at least one random access memory (RAM1502) and at least one read-only memory (ROM1504). All of these elements are in communication with a central processing unit (CPU1506) to facilitate the operation of thecomputing device1500. Thecomputing device1500 may be configured in many different ways. For example, thecomputing device1500 may be a conventional standalone computer or alternatively, the functions ofcomputing device1500 may be distributed across multiple computer systems and architectures. InFIG. 15, thecomputing device1500 can be linked, via network or local network, to other servers or systems.

Thecomputing device1500 may be configured in a distributed architecture, wherein databases and processors are housed in separate units or locations. Some units perform primary processing functions and contain at a minimum a general controller or a processor and a system memory. In distributed architecture implementations, each of these units may be attached via thecommunications interface unit1508 to a communications hub or port (not shown) that serves as a primary communication link with other servers, client or user computers and other related devices. The communications hub or port may have minimal processing capability itself, serving primarily as a communications router. A variety of communications protocols may be part of the system, including, but not limited to: Ethernet, SAP, SAS™, ATP, BLUETOOTH™, GSM and TCP/IP.

TheCPU1506 comprises a processor, such as one or more conventional microprocessors and one or more supplementary co-processors such as math co-processors for offloading workload from theCPU1506. TheCPU1506 is in communication with thecommunications interface unit1508 and the input/output controller1510, through which theCPU1506 communicates with other devices such as other servers, user terminals, or devices. Thecommunications interface unit1508 and the input/output controller1510 may include multiple communication channels for simultaneous communication with, for example, other processors, servers or client terminals.

TheCPU1506 is also in communication with the data storage device. The data storage device may comprise an appropriate combination of magnetic, optical or semiconductor memory, and may include, for example,RAM1502,ROM1504, and a flash drive, an optical disc such as a compact disc or a hard disk or drive. TheCPU1506 and the data storage device each may be, for example, located entirely within a single computer or other computing device; or connected to each other by a communication medium, such as a USB port, a serial port cable, a coaxial cable, an Ethernet cable, a telephone line, a radio frequency transceiver or other similar wireless or wired medium or combination of the foregoing. For example, theCPU1506 may be connected to the data storage device via thecommunications interface unit1508. TheCPU1506 may be configured to perform one or more particular processing functions.

The data storage device may store, for example, (i) anoperating system1512 for thecomputing device1500; (ii) one or more applications1514 (for example, computer program code or a computer program product) adapted to direct theCPU1506 in accordance with the systems and methods described here, and particularly in accordance with the processes described in detail with regard to theCPU1506; or (iii) database(s)1516 adapted to store information that may be utilized to store information required by the program.

Theoperating system1512 andapplications1514 may be stored, for example, in a compressed, an un-compiled and an encrypted format, and may include computer program code. The instructions of the program may be read into a main memory of the processor from a computer-readable medium other than the data storage device, such as from theROM1504 or from theRAM1502. While execution of sequences of instructions in the program causes theCPU1506 to perform the process steps described herein, hard-wired circuitry may be used in place of, or in combination with, software instructions for implementation of the processes of the present disclosure. Thus, the systems and methods described are not limited to any specific combination of hardware and software.

Suitable computer program code may be provided for performing one or more functions in relation to editing a sub-section of an electronic document via a notification message as described herein. The program also may include program elements such as anoperating system1512, a database management system and “device drivers” that allow the processor to interface with computer peripheral devices (for example, a video display, a keyboard, a computer mouse, etc.) via the input/output controller1510.

The term “computer-readable medium” as used herein refers to any non-transitory medium that provides or participates in providing instructions to the processor of the computing device1500 (or any other processor of a device described herein) for execution. Such a medium may take many forms, including but not limited to, non-volatile media and volatile media. Non-volatile media include, for example, optical, magnetic, or opto-magnetic disks, or integrated circuit memory, such as flash memory. Volatile media include dynamic random access memory (DRAM), which typically constitutes the main memory. Common forms of computer-readable media include, for example, a floppy disk, a flexible disk, hard disk, magnetic tape, any other magnetic medium, a CD-ROM, DVD, any other optical medium, punch cards, paper tape, any other physical medium with patterns of holes, a RAM, a PROM, an EPROM or EEPROM (electronically erasable programmable read-only memory), a FLASH-EEPROM, any other memory chip or cartridge, or any other non-transitory medium from which a computer can read.

Various forms of computer readable media may be involved in carrying one or more sequences of one or more instructions to the CPU1506 (or any other processor of a device described herein) for execution. For example, the instructions may initially be borne on a magnetic disk of a remote computer (not shown). The remote computer can load the instructions into its dynamic memory and send the instructions over an Ethernet connection, a cable line, or even a telephone line using a modem. A communications device local to a computing device1500 (for example, a server) can receive the data on the respective communications line and place the data on a system bus for the processor. The system bus carries the data to main memory, from which the processor retrieves and executes the instructions. The instructions received by main memory may optionally be stored in memory either before or after execution by the processor. In addition, instructions may be received via a communication port as electrical, electromagnetic or optical signals, which are exemplary forms of wireless communications or data streams that carry various types of information.

While various embodiments of the present disclosure have been shown and described herein, it will be obvious to those skilled in the art that such embodiments are provided by way of example only. Numerous variations, changes, and substitutions will now occur to those skilled in the art without departing from the disclosure. It should be understood that various alternatives to the embodiments of the disclosure described herein may be employed in practicing the disclosure. It is intended that the following claims define the scope of the disclosure and that methods and structures within the scope of these claims and their equivalents be covered thereby.

Claims (20)

What is claimed is:

1. A method of storing metadata for a file on a cloud based storage system, the method comprising:

receiving, from a third party application, a request to store metadata for a file, the metadata having a metadata type and a metadata value, wherein the file has a proprietary document model that is specific to a native application and not the third party application;

determining the metadata type based on the request;

associating the metadata value with an application identifier, wherein the application identifier identifies the third party application; and

storing, with the file on the cloud based storage system, the metadata type and metadata value in association with the application identifier, such that the third party application has access to the metadata type and the metadata value without having access to the proprietary document model, wherein the metadata value comprises information related to an anchor corresponding to a geometrically-defined location of a portion of content within the file when the portion of content within the file is graphically displayed to a user.

2. The method ofclaim 1, wherein the metadata value comprises information related to a plurality of anchors in the file, each anchor corresponding to a respective location of a respective portion of content within the file, and the metadata value being indicative of the respective locations of the respective portions.

3. The method ofclaim 1, wherein the anchor comprises a type and an attribute of the file, and wherein the anchor changes as the attribute changes based on the type.

4. The method ofclaim 3, wherein the attribute comprises one from the group of: a point of time in the file, a byte position in the file, a pixel location in the file, a page in the file, a cell in a grid in the file, and an index of an object in the file.

5. The method ofclaim 1, further comprising:

determining revision information for the file, wherein the revision information is based on a modified version of the file; and

associating the metadata value with the revision information for the file.

6. The method ofclaim 1, further comprising:

associating the metadata value with revision information by automatically storing the revision information corresponding to a revision of the file at a time when the metadata value is stored;

identifying a first revision number associated with the content of the file;

identifying a second revision number associated with the metadata;

comparing the first revision number to the second revision number;

providing a display of the content with an indication of the metadata when the first revision number matches the second revision number; and

providing a display of the content without an indication of the metadata when the first revision number does not match the second revision number.

7. The method ofclaim 1, further comprising:

receiving from the third party application a request for the metadata value for the file; and

transmitting to the third party application at least one metadata value based on the determined metadata type.

8. The method ofclaim 7, further comprising:

determining file revision information for the file based on the request for metadata for the file, wherein the file revision information is based on a modified version of the file;

determining metadata revision information, wherein the metadata revision information comprises file revision information associated with the metadata; and

transmitting to the third party application at least one metadata value based on the determined metadata type and the determined metadata revision information.

9. The method ofclaim 1, wherein the metadata value comprises information related to a thumbnail of the file that includes a compressed version of the content in the file, wherein the anchor corresponding to the metadata value is null, indicating that the anchor is not related to any third party application.

10. The method ofclaim 1, wherein the anchor is associated with the application identifier.

11. A system for storing metadata for a file on a cloud based storage system, the system comprising a processor configured to:

receive from a third party application a request to store metadata for a file, the metadata having a metadata type and a metadata value, wherein the file has a proprietary document model that is specific to a native application and not the third party application;

determine the metadata type based on the request;

associate the metadata value with an application identifier, wherein the application identifier identifies the third party application; and

store, with the file on the cloud based storage system, the metadata type and metadata value in association with the application identifier, such that the third party application has access to the metadata type and the metadata value without having access to the proprietary document model, wherein the metadata value comprises information related to an anchor corresponding to a geometrically-defined location of a portion of content within the file when the portion of content within the file is graphically displayed to a user.

12. The system ofclaim 11, wherein the metadata value comprises information related to a plurality of anchors in the file, each anchor corresponding to a respective location of a respective portion of content within the file, and the metadata value being indicative of the respective locations of the respective portions.

13. The system ofclaim 11, wherein the anchor comprises a type and an attribute of the file, and wherein the anchor changes as the attribute changes based on the type.

14. The system ofclaim 13, wherein the attribute comprises one from the group of: a point of time in the file, a byte position in the file, a pixel location in the file, a page in the file, a cell in a grid in the file, and an index of an object in the file.

15. The system ofclaim 11, wherein the processor circuitry is further configured to:

determine revision information for the file, wherein the revision information is based on a modified version of the file; and

associate the metadata value with the revision information for the file.

16. The system ofclaim 11, wherein the processor circuitry is further configured to:

associate the metadata value with revision information by automatically storing the revision information corresponding to a revision of the file at a time when the metadata is stored;

identify a first revision number associated with the content of the file;

identify a second revision number associated with the metadata;

compare the first revision number to the second revision number;

provide a display of the content with an indication of the metadata when the first revision number matches the second revision number; and

provide a display of the content without an indication of the metadata when the first revision number does not match the second revision number.

17. The system ofclaim 11, wherein the processor circuitry is further configured to:

receive from the third party application a request for the metadata for the file; and

transmit to the third party application at least one metadata value based on the determined metadata type.

18. The system ofclaim 17, wherein the processor is further configured to:

determine file revision information for the file based on the request for metadata for the file, wherein the file revision information is based on a modified version of the file;

determine metadata revision information, wherein the metadata revision information comprises file revision information associated with the metadata value; and

transmit to the third party application at least one metadata value based on the determined metadata type and the determined metadata revision information.

19. The system ofclaim 11, wherein the metadata comprises information related to a thumbnail of the file that includes a compressed version of the content in the file, and wherein the anchor corresponding to the metadata value is null, indicating that the anchor is not related to any third party application.

20. The system ofclaim 11, wherein the anchor is associated with the application identifier.

Images