Abstract:
The present disclosure provides a system and method for mapping zone-based metadata into one or more reference-able objects. The system and method extracts and/or generates metadata from a document according to custom zones defined in a document type. Each custom zone is associated to actions such as generating events, invoking triggers and/or invoking callback methods. One or more of these actions may be triggered when pre-processing or post-processing a document. According to an inventive concept of the present application, when a document is stored in a data storage and placed in a process queue to be processed by a suitable processing plugin according to the custom zones defined in the document. For instance, an image file comprising textual custom zones may be processed by an OCR plugin which extracts text metadata from the document. Other processing plugins include plugins to extract metadata from proprietary document formats such as CAD, PPTX, PDF, PSD, or others. Plugins are also available for generation of metadata by interpreting an image (i.e. detection or identification of objects and/or scenery in an image) through artificial intelligence and computer vision means. The process queue can be used for scalability of the quantity of actions to process.

Description:
BACKGROUND 
     Systems and methods for metadata extraction, generation, mapping and execution have been described in the computer arts with varying degrees of success. 
     For instance, U.S. Patent Publication US 2013/0294694 (Zhang) teaches a method for zone-based metadata extraction that allows users to select zones in a text document in order to extract metadata using optical character recognition (OCR) on said zones and to store the metadata in a database. 
     U.S Patent Publication US2008/0162603 (Garg) teaches a method whereby an image document is turned into a text document. According to Garg, the user creates a template specifying the portions of an image document to be OCR&#39;d. The system then receives a document, extracts textual metadata from said document and stores said metadata on a storage. 
     Similarly, U.S. Pat. No. 8,693,790 (Jiang) teaches a form template definition method. The form template definition method comprises a cell extraction step of analyzing an image thereby extracting one or more cells from the image. The method further includes a cell classification step of classifying the extracted cells and a cell attribute definition step of defining attributes of the extracted cells class by class. The inventive step behind Jiang is related to automatically copying the common attributes of a first cell to other cells. 
     However, none of the references provide an architecture to perform pre-processing or post-processing of a given document in order to perform actions based on a document type. The present disclosure overcomes the limitations found in the relevant art. 
     BRIEF SUMMARY 
     The present disclosure provides a system and method for mapping zone-based metadata into one or more reference-able objects. The system and method extracts and/or generates metadata from a document according to custom zones defined in a document type. Each custom zone is associated to actions such as generating events, invoking triggers and/or invoking callback methods. One or more of these actions may be triggered when pre-processing or post-processing a document. 
     The document can be input to the system through an Application Program Interface (API), a web interface accessible through an Internet browser, an e-mail protocol, a local or remote storage, or other file transfer protocols such as FTP, SCP, or SSH. The document format may be an image file such as a scanned file, a flattened image or any document format such as word processor files, CAD files, proprietary image files and the like. 
     According to an inventive concept of the present application, a document is stored in a data storage and placed in a process queue to be processed by a suitable processing plugin according to the custom zones defined in the document. For instance, an image file comprising textual custom zones may be processed by an OCR plugin which extracts text metadata from the document. Other processing plugins include plugins to extract metadata from proprietary document formats such as CAD, PPTX, PDF, PSD, or others. Plugins are also available for generation of metadata by interpreting an image (i.e. detection or identification of objects and/or scenery in an image) through artificial intelligence and computer vision means. The process queue can be used for scalability of the quantity of actions to process. 
     The data storage of the document types, documents or metadata may be of any suitable type such as object storage, file share storage, block storage, a path to a local folder, a database, raw disk access, magnetic media or in-memory storage. 
    
    
     
       BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS 
         FIG. 1  illustrates a document and its corresponding document type. 
         FIG. 2  illustrates the steps to extract or generate metadata elements from a document. 
         FIG. 3  illustrates an exemplary cloud system to perform the zone-based metadata extraction method. 
         FIG. 4  illustrates an aspect of the first plugin services in accordance with one embodiment. 
         FIG. 5  illustrates scalability of the queue service. 
         FIG. 6  illustrates a routine in accordance with one embodiment. 
     
    
    
     DETAILED DESCRIPTION 
       FIG. 1  shows an exemplary document  100  with one or more zones comprising company name  102 , order number  104 , recipient  106 , page number  108 , date 110, delivery number  112  associated to a document type. The document type may also have a default zone corresponding to the totality of the document  100 . In one embodiment, each page in its entirety is considered the default zone. The user can define new zones and associate them to a reference-able object. For instance, the user may map company name  102  to a reference-able object named Company_Name. Likewise, order number  104  may be mapped to reference-able object Order_Num, and so on. These zone definitions are associated to the document type “Invoices Template A.” When an OCR first plugin service processes document  100 , it stores the extracted or generated data in an object associated to an order document type. 
     Referring to  FIG. 1 , the OCR first plugin service processes document  100  and extracts company name  102 , order number  104 , recipient  106 , page number  108 , date 110, and delivery number  112 . Multi-page documents may be detected, for example, by identifying the page number  108 . When a multi-page document type is encountered, the system may store each page of the multi-page document separately to be processed by independent OCR first plugin services. The data from each independent OCR first plugin service may be stored on a single object which may trigger only when the totality of the multi-page document is received. 
     According to an embodiment shown in  FIG. 2 , in step  200 , the system retrieves metadata from zones associated to a document type. In step  204 , the system extracts or generates metadata for each zone in the document type. In step  206 , the system verifies if the object requires metadata from each zone to be consolidated. In step  208 , if metadata consolidation is required, the system instantiates a single object and assigns metadata to it. In step  210 , if metadata consolidation is not required, the system instantiates one reference-able object per non-consolidated zones. 
     In step  212  and step  214 , if the object requires triggering an event or an action, the system performs the required events or actions occasionally sending the object or sharing the object by, for example, storing the object in a shared storage. In step  216 , after the triggers are processed, the extracted or generated metadata is stored or replicated to the data storage. 
     As shown in  FIG. 2 , the service retrieves zones for the document type and registers the document in a queue for processing. The appropriate plugins are notified of the existence of a document to extract or generate additional metadata from the document type zones, store the metadata in a persistent or ephemeral storage, and associate the metadata to the original document. The metadata can be stored in one or more formats. Metadata can be used for dynamic indexing of the original document or to invoke actions. 
     Once the metadata is extracted, generated or both for a particular zone, the service can be configured to group metadata from multiple zones into a single reference-able object or each zone can be mapped to a unique reference-able object. After the definition of the reference-able object the metadata and object can be stored for future reference or an event or action can be triggered. 
     Examples of an action or events include invoking another script or program, interact with an API or programmable interface, and other similar actions. 
     The metadata generation method includes processing and interpreting the contents of said document based on the document type. Advanced techniques, like computer vision and artificial intelligence, are used to analyze documents like images, diagrams, illustrations, photos, etc., and identify objects and scenery in the document. This identified information is included as part of the metadata associated to the original document. 
     Some proprietary formats like CAD, PST and others, can be interpreted by specialized plugins to detect internal labels, descriptions, annotations and other, which then can be set as part of the metadata associated to the original document. 
     As shown in  FIG. 3 , a document is a digital object to be processed by the services. When a new document is uploaded to the system by server  302 , the service receives the digital object and initial metadata and stores it on object and metadata storage  308  which may comprise a persistent storage or ephemeral storage. For scalability and concurrent notification of multiple processes or micro services, a queue  312  can be used to register plugin notification through the channels relevant to their process or micro service. The queue  312  retrieves the zones of the corresponding document type and notifies other processes or micro services about the existence of the new document. These processes or micro services can be referred as plugins. An example of a plugin is OCR first plugin service  314  which affords optical character recognition (OCR) processing of a zone. 
     According to one embodiment, the system receives image  304  or file  306  (such as document  100 ) from server  302  and stores it in an object and metadata storage  308 . If the plurality of zones in the image  304  or file  306  is associated to textual characters, the queue  312  notifies the OCR first plugin service  314  which processes each zone to extract the corresponding textual metadata elements. The OCR first plugin service  314  then assigns the textual metadata element to one or more objects associated to the document type which is stored in the metadata storage  318 . 
     Other plugin services  316  may include capabilities for computer vision, artificial intelligence, and other technologies. If the plurality of zones are associated to one or more triggers, the system executes those triggers appropriately. Metadata storage  318  may replicate some or all of its data to object and metadata storage  308 . 
     Advantageously, to upload a document to the service the server  302  can interact directly with APIs, Web Interface or many others. Capabilities to express the initial metadata of the document varies accordingly. 
     A preferred embodiment includes an API (i.e. RESTful Interface) to upload documents into the service. Interaction using the native API provides the ability to encode metadata as JSON, XML or other HTTP compliant data encoding mechanisms. When using the API, one or more documents may be uploaded at the same time. 
     The service supports various techniques to upload document over email. The user can configure a mailbox (IMAP, POP, etc) for the service to download email with attachments. The service can also be configured to enable direct reception of email using protocols like SMTP, ActiveSync, etc. By default, the attachments are processed as new documents. The user can opt to have a mailbox per document type or a single mailbox for multiple document types and include a special attachment to provide metadata and document type information to the service about the attachments. (i.e. Use a “metadata.yaml” file to encode metadata and document type classification of the other attachments in the email). The email itself can be map to a document type for email archiving or audit trails. 
     A filesystem folder or directory, local or remote (i.e. NFS, CIFS, etc.) can be used to upload documents to the service. Subfolders can be map to document types and special files (i.e. “metadata.yaml”) can be used to map metadata to the documents in the folder. File sync and share services like Dropbox, Google Drive, iCloud Drive, etc, can be used as sources of document to the service. Techniques similar to the Folder can be used to upload and assign metadata to documents. Further, transfer protocols (i.e. FTP, SCP, SSH, etc) can be configured as targets to upload data using techniques similar to the Folders. 
     Other sources for documents may be used. For instance, multi-functional machines can be configured to send documents over email, folder, FTP servers or other supported source types, to upload documents to the service. Traditional scanners can be used to capture images or PDF of the documents and then use any of the supported source types to upload the documents to the service. Cameras can use to capture images and upload these as documents using any of the supported source types. Finally, protocols like WebDav, S3, Swift, RADOS and others are example of protocols which could be part of document source types maintaining the same capabilities. 
     In some embodiments, a computing system may include a first processor; a second processor; an object and metadata storage; a metadata storage; and/or a first memory storing instructions that, when executed by the first processor, configure the system store a document type, including a group of zones, in the object and metadata storage and assigning one or more triggers to one or more zones in the group of zones. The system is further configured to receive a document associated with the document type, storing the document in a queue service. The system then notifies a first plugin service associated to the one or more zones in the group of zones (such as OCR first plugin service  314 ). 
     The embodiment further includes a second memory storing instructions that, when executed by the second processor, configure the system to: extract, by the first plugin service, a metadata element associated to the one or more zones in the group of zones. The extracted (or generated) metadata element is assigned to one or more objects associated to the document type and these objects are stored in the metadata storage. Finally, the system invokes the one or more triggers assigned to the one or more zones in the group of zones. 
     In some embodiments, such a computing system may further include a third processor; wherein the first memory storing instructions further configures the first processor to notify a second plugin service associated to the one or more zones in the group of zones (such as any of the plugin services  316 ); and a third memory storing instructions that, when executed by the third processor, configure the system to extract, by the second plugin service, a metadata element associated to the one or more zones in the group of zones. The extracted (or generated) metadata element is assigned to one or more objects associated to the document type and these objects are stored in the metadata storage. Finally, the system invokes the one or more triggers assigned to the one or more zones in the group of zones. 
     In another embodiment, as shown in  FIG. 4 , the system includes a first plugin service to generate metadata by interpreting the contents of an image. For example, images  402  are processed by routines  404  to generate metadata according to the scenery and objects detected in the image. Generated metadata elements  406  may be stored in a particular object as text or any other suitable data type used to represent the contents of images  402 . 
     As shown in  FIG. 5 , the event, trigger, or action may employ a queue  312  to which other processes or micro services can be registered to react and execute additional tasks or invoke sub-actions. Once metadata is extracted from a zone, events can be generated and triggers can be invoked. These actions  504  are stored in a queue  312  which executes the tasks  508 . Actions  504  placed in the queue  312  may comprise sub-actions  506  performed sequentially or in distributed fashion. In one embodiment, actions  504  may be performed by independent processors. When the queue  312  detects that actions  504  in the queue are not timely processed, the queue  312  may scale the quality and quantity of processors to a suitable amount only while the surge of actions  504  is processed. After the queue  312  detects that the service does not require as many processors, it may scale down appropriately to avoid idle processors. 
     In block  602 , routine  600  stores a document type. In block  604 , routine  600  as signs one or more triggers to one or more zones in the plurality of zones. In block  606 , routine  600  receives a document associated with the document type. In block  608 , routine  600  stores the document in a queue service. In block  610 , routine  600  notifies a first plugin service associated to the one or more zones in the plurality of zones. In block  612 , routine  600  extracts, by the first plugin service. In block  614 , routine  600  assigns the metadata element to one or more objects associated to the document type. In block  616 , routine  600  stores the one or more objects associated to the document type. In block  618 , routine  600  invokes the one or more triggers assigned to the one or more zones in the plurality of zones. In done block  620 , routine  600  ends.