MXPA06001207A

MXPA06001207A - Organizacion automatizada de datos.

Info

Publication number: MXPA06001207A
Application number: MXPA06001207A
Authority: MX
Inventors: Praveen Seshadri
Original assignee: Microsoft Corp
Priority date: 2005-02-28
Filing date: 2006-01-30
Publication date: 2006-09-19
Also published as: EP1696315A3; CA2533797A1; RU2405193C2; KR20060095446A; BRPI0600057A; KR101219856B1; AU2006200232B2; CN1828530B; CA2533797C; RU2006102136A; US20060195850A1; EP1696315B1; AU2006200232A1; JP5255184B2; US7565663B2; CN1828530A; JP2006244468A; EP1696315A2

Abstract

Se presente un sistema para automatizar el procesamiento de datos. El sistema comprende un modulo de programacion de usuario final que esta integrado con un sistema de archivo importante y que delinea un evento de un sistema de computo para al menos una accion automatica que es definida por un usuario final. El sistema tambien incluye un controlador de evento que responde a eventos y causa que se realice al menos una accion automatica. Tambien se proporcionan metodos para utilizar el sistema.

Description

ORGAN IZACIÓN AUTO MATIZADA DE DATOS REFERENCIA CRUZA A SOLIC ITUD RELACIONADA Esta es una solicitud que reclama un beneficio bajo 35 U . S.C. § 1 1 9 (e) de la solicitud de patente provisional de E. U. A. Serie No. 60/657,519, intitulada "Organización Automatizada de Datos" y presentada el 28 de febrero, 2005. La totalidad de la solicitud antes mencionada, incluyendo todos los anexos o exhibiciones de la misma, es por lo tanto incorporada aquí por referencia.

ANTECEDENTES Los sistemas de cómputo modernos pueden incluir muchos procedimientos de software activos en cualquier momento en varios estados de ejecución. Este procedimiento puede ser iniciado por un sistema operativo, puede verificar o servir procedimientos que son iniciados en el tiempo de inicio o al lanzar una aplicación de usuario, o puede ser una misma aplicación de usuario. Muchos, si no es que la mayoría de estos procedimientos o características de estos procedimientos, están más allá de la habilidad de un usuario para controlar directamente. Por lo tanto, si la funcionalidad ofrecida por estos procedimientos va a ser accedida del todo, tal acceso usual y típicamente debe ser realizado por otro procedimiento de software . Las aplicaciones de software manejan información a beneficio de usuarios finales. El número de aplicaciones de software o procedimientos que corren en un sistema de cómputo generalmente es una función de la cantidad de datos que el sistema debe procesar y en números de tareas que el sistema es llamado para realizar. Las últimas partes eficientes de estos deberes de cómputo son las que requieren interacción humana. A pesar del aumento de máquinas de energía, los usuarios finales típicamente tienen que procesar manualmente un gran número de información computarizada. Un componente mayor de un sistema de cómputo general es un dispositivo de almacenamiento tal como una unidad de disco duro, que comúnmente es utilizada para almacenamiento persistente de información electrónica tal como archivos de datos y programas ejecutables. Para organizar información electrónica para que pueda ser localizada y recuperada en una forma útil, se puede emplear un sistema de archivo. Existen muchos sistemas de archivo pero generalmente todos proporcionan un diseño de organización conceptual para el formato y ubicación de información en un dispositivo de almacenamiento. El diseño de organización conceptual proporcionado por un sistema de archivo puede ser empleado por procedimientos de software como aquellos de un sistema operativo para crear, acceder, recuperar, eliminar, y de otra forma manejar información almacenada en el dispositivo de .almacenamiento. Para proteger la integridad del sistema de archivo y asegurar la adherencia al formato del sistema de archivo, generalmente solo ciertos procedimientos de software privilegiados como procedimientos de entrada-salida de un sistema operativo son permitidos con acceso directo al sistema de archivo . Las aplicaciones y los usuarios que acceden a un sistema de archivo generalmente deben de hacerlo a través de funciones proporcionadas por el sistema operativo. Estas funciones usualmente están ocultas de la vista de usuarios finales que pueden incluso no saber la existencia de estas funciones. Comúnmente, este acceso restringido resulta en la incapacidad de un usuario para explotar completamente las características del sistema de archivo para hacer las tareas de cómputo más fáciles, por ejemplo, al utilizar atributos del sistema de archivo para automatizar tareas tal como organización o ubicación de archivo. Generalmente, un usuario final maneja información en su computadora de acuerdo con un ciclo de vida de información. Durante ese ciclo de vida, el usuario final usualmente crea información o, obtiene información de alguna fuente, y la información después es almacenada en un sistema de archivo. En algún punto, el usuario final recupera la información y toma acción basándose en esa información. Este ciclo puede ser repetido muchas veces. Los sistemas actuales no proporcionan a un usuario final para automatizar porciones de este ciclo de vida en las formas en que son eficientes y personalizadas para las necesidades del usuario final.

COMPENDIO DE LA INVENCIÓN Lo siguiente presenta un compendio simplificado con el fin de proporcionar un entendimiento básico. Este compendio no es una revisión extensiva. Tampoco pretende identificar elementos claves o críticos de la invención ni delinear el alcance. Su único propósito es presentar algunos conceptos en una forma simplificada como un preludio a la descripción más detallada que es presentada más adelante. Adicionalmente, los encabezados de sección utilizados aquí son proporcionados solamente para conveniencia y no deben ser tomados en una forma limitante. Un módulo de programación de usuario final proporciona una capacidad para que los usuarios de término de un sistema de cómputo identifiquen eventos que puede servir como impulsadores para una o más acciones definidas por usuarios. Los usuarios finales pueden, al utilizar el módulo, definir tareas de procesamiento de datos para ser automáticamente realizadas con la ocurrencia de un vento elegido. Estas tareas de procesamiento de datos pueden incluir organización de archivo y filtrados de archivo para atributos o contenido, entre otras tareas. El desempeño de tales tareas puede ser realizado por uno o más componentes del sistema de cómputo. De esa forma, a manera de módulos de programación de usuario final, los usuarios pueden generar programas de usuario final adaptados para ayudar al almacenamiento y organización de datos. Los programas de usuario final creados con un módulo de programación de usuario final pueden ser creados de uno o más tipos básicos, que pueden ser combinados para formar entidades completas que pueden ser utilizadas para realizar tareas. Los tipos básicos además pueden ser combinados con otros componentes para realizar tareas más complicadas. Las acciones a ser realizadas pueden ser impulsadas automáticamente por un evento preseleccionado sin la necesidad de que el usuario final inicie las acciones o interactúe con un sistema de cómputo mientras las tareas están siendo realizadas. Por lo tanto, más que sea forzado a revisar los datos y hacer decisiones con respecto a donde almacenar tales datos, un usuario puede, a través del uso de los tipos de base antes mencionados, causar que tales datos sean automáticamente filtrados y almacenados en una ubicación deseable. Además, las acciones pueden ser automáticamente realizadas con la ocurrencia de un evento tal como recibo de datos). En un ejemplo, el usuario puede especificar que cada vez que se reciba un mensaje de correo electrónico de un individuo particular se invocará una aplicación de envío de mensaje instantáneo y se entregará un mensaje instantáneo a un contacto particular. De esa forma, se puede discernir que las acciones específicas pueden ocurrir a través de aplicaciones diferentes a través del uso de los tipos básicos (o combinación de tipos básicos). En otro ejemplo, las acciones definidas por un usuario pueden ser explícitamente invocadas a través de un comando desde un usuario final. Para ayudar a la utilidad, un sistema de programación de usuario final puede ser integrado con un sistema de archivo para proporcionar una interfase uniforme para información almacenada en un sistema de cómputo. La integración entre el módulo de programación de usuario final y el sistema de archivo proporciona una capacidad para que un usuario final defina reglas y acciones a ser tomadas en los datos almacenados, en donde las reglas pueden ser aplicadas y las acciones se pueden tomar en los datos con o sin interacción de usuario. Este tipo de sistema de programación de usuario final puede proporcionar a un usuario final la capacidad de manejar datos utilizando funciones del sistema de archivo importante que de otra forma seguirán ocultadas y que el usuario final estaría prohibido para acceder. Los componentes y métodos mencionados y descritos comprenden las características aquí más completamente descritas y particularmente señaladas en las reivindicaciones. La siguiente descripción y dibujos anexos mencionan en detalle ciertos ejemplos ilustrativos. Estos aspectos son indicativos, sin embargo, de alguna de las varias formas diferentes en las cuales los componentes y métodos mencionados pueden ser empleados. Las implementaciones específicas de los componentes y métodos mencionados y descritos pueden incluir algunos, muchos, o todos tales componentes, métodos y sus equivalentes. Las variaciones de las implementaciones específicas y ejemplos presentados aquí serán evidentes a partir de la siguiente descripción detallada cuando se consideran en conjunto con los dibujos.

BREVE DESCRIPCIÓN DE LOS DIBUJOS La Figura 1 es un diagrama de bloque de sistema de un sistema de programación de usuario final. La Figura 2 es un diagrama de bloque de sistema de un sistema de procesamiento de usuario final. La Figura 3 es un diagrama de esquema de un esquema de reglas. La Figura 4 es un diagrama de bloque de sistema de un sistema de programación de usuario final con un sistema de archivo integrado. La Figura 5 es un diagrama de bloque de sistema de un sistema de programación de usuario final con un sistema de archivo integrado. La Figura 6 es un diagrama de bloque de sistema de un sistema de programación de usuario final con un sistema de archivo integrado. La Figura 7 es un diagrama de bloque de sistema de un sistema de programación de usuario final con un sistema de archivo integrado. La Figura 8 es un diagrama de flujo de un método de procesamiento general que puede ser utilizado junto con componentes que son mencionados y descritos aquí. La Figura 9 es un diagrama de flujo de un método del procesamiento general que puede ser utilizado junto con componentes que son mencionados y descritos aquí. La Figura 10 es un diagrama de flujo de un ciclo de vida de información. La Figura 1 1 es un diagrama de bloque del sistema de un ambiente en red ilustrativo. La Figura 12 es un diagrama de bloque de sistema de un ambiente operativo ilustrativo.

DESCRIPCIÓN DETALLADA DE LA INVENCIÓN Como se utiliza en esta aplicación, los términos "componente", "sistema", "módulo", y similares pretenden referirse a una entidad relacionada con computadora, tal como hardware, software (por ejemplo, en ejecución), y/o firmware. Por ejemplo, un componente puede ser un proceso que corre en un procesador, un procesador, un objeto, un ejecutable, un programa, y/o una computadora. También, tanto una aplicación que corre en un servidor como el servidor pueden ser componente. Uno o más componentes pueden residir dentro de un procedimiento y un componente puede estar localizado en una computadora y/o distribuido entre dos o más computadoras. Los componentes y métodos mencionados son descritos con referencia a los dibujos, en donde números de referencia similares son utilizados para referirse del todo a elementos similares. En la siguiente descripción, para propósitos de explicación, numerosos detalles específicos son mencionados con el fin de proporcionar un entendimiento completo del asunto sujeto descrito. Puede ser evidente, sin embargo, que ciertos de estos detalles específicos pueden ser omitidos o combinados con otros en una implementación específica. En otros casos, ciertas estructuras y dispositivos son mostrados en forma de diagrama de bloque con el fin de facilitar la descripción. Adicionalmente, aunque ejemplos específicos descritos pueden utilizar terminología que es consistente con las arquitecturas de cliente/servidor o incluso pueden ser ejemplos de implementaciones de cliente/servidor, los expertos en la técnica apreciarán que los papeles de cliente y servidor pueden ser invertidos, que los componentes y métodos mencionados y descritos no están limitados a arquitecturas de cliente/servidor y pueden adaptados fácilmente para utilizarse en otras arquitecturas, específicamente incluyendo arquitecturas par a par (P2P), sin apartarse del espíritu o alcance de los componentes y métodos mencionados y descritos. Además, se debe notar que aunque los ejemplos específicos aquí presentados incluyen componentes específicos de referencia, una implementación de los componentes y métodos mencionados y descritos aquí no necesariamente están limitados a aquellos componentes específicos y pueden ser empleados también en otros contextos. Los sistemas a base de inteligencia artificial (por ejemplo , clasificadores explícitamente y/o implícitamente entrenados) pueden ser empleados en conexión con realización de inferencia y/o determinaciones probabilístícas y/o determinaciones a base estadística de acuerdo con uno o más aspectos de la invención sujeta como se describe aquí más adelante. Como se utiliza aquí, el término "inferencia" generalmente se refiere a procedimiento de razonar sobre o inferir estado del sistema, ambiente, y/o usuario de un grupo de observaciones cuando se capturan a través de eventos y/o datos. La inferencia puede ser empleada para identificar un contexto o acción específico, o puede generar una distribución de probabilidad en estados, por ejemplo. La inferencia puede ser probabilística, eso es, el cálculo de una distribución de probabilidad en estados de interés basándose en una consideración de datos y eventos. La inferencia también puede referirse a técnicas empleadas para componer eventos de nivel superior de un grupo de eventos y/o datos. Tal inferencia resulta en la construcción de nuevos eventos o acciones de un grupo de eventos observados y/o datos de evento almacenados, ya sea que los eventos estén o no correlacionados en proximidad temporal cercana, y si los eventos y datos vienen de uno o diferentes eventos y fuentes de datos. Varios esquemas de clasificación y/o sistemas por ejemplo, máquinas de vector de soporte, redes neurales, sistemas de experto, redes de creencia Bayesiana, lógica confusa, y máquinas de fusión de datos, entre otros, pueden ser empleados en conexión con realizar acción automática y/o inferida en conexión con los componentes y métodos mencionados y descritos aquí. La Figura 1 es un diagrama de bloque de sistemas de un sistema de programación de usuario final 100. El sistema de programación de usuario final 100 incluye una plataforma operativa 1 1 0, que puede proporcionar un ambiente de procesam iento para el sistema de programación de usuario final 100. En este contexto, la plataforma operativa 1 1 0 puede incluir tanto componentes de hardware como de software. Específicamente, la plataforma operativa 1 1 0 puede ser un sistema operativo para una computadora personal , una estación de trabajo, o un servidor. Un evento 120 puede ser creado por la plataforma operativa 1 10, en donde ei evento 120 puede servir como un indicador de que una tarea de procesamiento está siendo o ha sido realizada. U n evento tal como el evento 120 puede ser detectado por otros componentes de cómputo y puede ser utilizado como un dispositivo de impulso para iniciar la ejecución de una tarea de cómputo predefinida. Un módulo de programación de usuario final ("EU P") 130 puede proporcionar un componente que puede ser operado por un usuario final para definir una acción, tal como una acción definida por usuario 140, para ser tomada con la ocurrencia del evento 120. Se debe notar que la acción definida por usuario 140 puede ser una tarea individual o puede ser un grupo de tareas a ser realizado. El módulo EU P 130 puede proporcionar una interfase a funciones de sistemas que pueden ser operadas manualmente o previamente solo o bien ser accedida por otros componentes de software tal como , pero no limitándose a, un sistema operativo con componentes de servicio. En operación , el usuario final accede al módu lo de EU P 1 30 para identificar un evento, tal como el evento 120, que puede ser utilizado para impulsar una acción definida por usuario. El usuario final también define una acción o grupo de acciones que el usuario final desea que el sistema ejecute automáticamente con la ocurrencia del evento identificado. El evento después está limitado a la acción definida por usuario, en otras palabras, con la ocurrencia del evento 120, la plataforma operativa realiza la acción definida por usuario. Por ejemplo, un usuario final puede identificar la recepción de un mensaje de correo electrónico de una persona particular como un evento de impulso. El usuario final después puede crear una acción que con el recibo de tal mensaje de correo electrónico, el mensaje es transferido a una carpeta de buzón de correo definida, un recibo de verificación de respuesta del mensaje es enviado al remitente, un documento es recuperado desde un servidor de archivo y abierto en un programa apropiado, y una alerta audible suena para notificar al usuario que el documento ya está en la computadora. Estos pasos pueden ser realizados automáticamente sin la intervención del usuario a través del uso del sistema 100. La Figura 2 es un diagrama de bloque de sistema de un sistema de procesamiento de usuario final 200. El sistema de procesamiento de usuario final 200 incluye una ¡nterfase de usuario 210 que puede proporcionar acceso al sistema para un usuario humano. La interfase de usuario 210 puede ser cualquier interfase de computadora humana apropiada, tal como una interfase de usuario gráfica, una interfase de unidad de comando, o una interfase a base de web, eh ir^ otros, y puede estar acopiado a una plataforma operativa 220 que pµede incluir tanto componentes de hardware corrió de software. La interfase de usuario 210 también puede estar conectada a un controlador de eventos 230 y un almacenamiento de datos de regla 240 en donde el controlador de evento 230 puede detectar la ocurrencia de un evento 245 y acceder a un subsistema de procesamiento 250. En la operación, la interfase de usuario 210 proporciona acceso al controlador de evento 230 y el almacenamiento de datos de regla 240 a un usuario final, que puede identificar un evento para ser utilizado como un evento de impulso y causar la unión de ese evento a una acción definida por usuario. La acción definida por usuario después puede ser almacenada dentro del almacenamiento de datos de regla 240. La plataforma operativa 220 crea un evento 245 que es detectado por el controlador de evento 230, que puede acceder al almacenamiento de datos de regla 240 para determinar si una acción definida por usuario está limitada al evento detectado. Si es así, el controlador de evento 230 accede al subsistema de procesamiento 250 para dirigir el desempeño de la acción definida por usuario. Las reglas a ser aplicadas durante la creación o ejecución de tareas definidas por usuario final pueden ser de acuerdo con un álgebra de regla. Los detalles de un álgebra de reglas apropiado que puede ser utilizado pueden variar ampliamente de acuerdo con una implementación específica de un módulo de EUP. Un álgebra de reglas ilustrativas es presentada y descrita en más detalle más adelante. El álgebra de reglas ilustrativo puede incluir varios componentes lógicos que pueden ser integrados para formar una plataforma de regla. Entre esos componentes están términos básicos que pueden servir como bloques de construcción para otros términos y expresiones. Los términos y expresiones que han sido construidos de otros términos o expresiones por sí mismos pueden ser utilizados como bloques de construcción para crear términos o expresiones más complejos. De esta manera, las regias complejas en aumento pueden ser creadas para ser aplicadas durante la ejecución de una tarea definida por usuario final. Una Propiedad(T) puede describir una propiedad de un tipo de usuario final T. Un usuario final puede utilizar una propiedad o propiedades para describir otro componente lógico, tal como un filtro o una acción. Una propiedad puede ser algún descriptor general de un tipo de usuario final T. Cuando se aplica al tipo diferente, tal como T o T-prima, el mismo descriptor puede ser utilizado. De esta manera, Propiedad(T) y Propiedad(T-prima) ambas pueden ser utilizadas como descriptores y pueden ser componentes diferentes. Una regla que tiene un tipo de artículo de entrada T y tipo de salida A puede ser definida como una propiedad de tipo O en tipo T. Un Filtro(T) puede ser una función Boleana que puede ser utilizada como un filtro en artículos de tipo T. Específicamente, un Filtro(T) puede ser una regla que regresa un tipo Boleano como un resultado de procesamiento de la ejecución de la regla. Una regla de Filtro(T) que es aplicada a un grupo de artículos puede filtrar artículos que no satisfacen una condición de la regla al examinar un valor para el tipo Boleano regresados siguiente la ejecución del Filtro(T) en un artículo individual en el grupo. Un artículo que satisface una condición de la regla de Filtro(T) puede impulsar la regla de Filtro(T) aplicada para regresar un valor de VERDADERO para el tipo Boleano regresado. En una forma similar, un artículo que no satisface una condición de la regla de Fiitro(T) aplicada puede impulsar a la regla de Filtro(T) para regresar un valor de FALSO para el tipo Boleano regresado. La regla de Filtro(T) puede ser interactivamente aplicado a cada artículo en un grupo para obtener subgrupos de artículos ya sea que satisfacen o fallan al satisfacer la condición de la regla de Filtro(T) aplicada. De esta manera, los subgrupos inclusivos o exclusivos pueden ser creados. Un subgrupo inclusivo puede tener artículos que satisfacen una condición de la regla de Filtro(T) aplicada y que impulsa un valor Boleano regresado de VERDADERO, resultando en aquellos artículos siendo descritos como incluidos. Un subgrupo exclusivo puede tener artículos que fallan al satisfacer una condición de la regla de Filtro(T) aplicada y que impulsa un valor de Boleano regresado de FALSO, que resulta en aquellos artículos siendo descritos como excluidos. Cualquier subgrupo puede ser utilizado en otro procesamiento. Una Acción(T) puede ser creada como un método de un artículo de tipo T, en donde el método puede tener algún efecto lateral deseado que crea un resultado. Típicamente, una Acción(T) puede utilizar o requerir otros parámetros. Una regla que tiene un tipo de entrada T y que saca un grupo cerrado puede definir una acción en artículos de tipo T. Un Grupo(T) es un agrupamiento de artículos de tipo T. U n Evento(T) puede ser utilizado para definir alguna ocurrencia de interés, y está típicamente asociado con un artículo de datos, por ejemplo, los datos de evento de tipo T. U n Evento(T) puede ser utilizado para definir un evento simple o puede ser utilizado como un bloque de construcción para crear un evento más complejo al utilizar una operación algebraica binaria. Cuando se combinan con un FiItro(T) , un Evento(T) puede ser util izado para crear un Evento(T) derivado. En términos algebraicos, EventoDerivado(T) = Evento(T) + Filtro(T) Generalmente, un evento derivado puede ser creado al aplicar un filtro a un evento . Otras interpretaciones también pueden ser formadas utilizando principios algebraicos. Por ejemplo, dos filtros en tipos de artículos complementarios (por ejemplo, dos tipos de ambos son subtipos del mismo tipo padre) pueden ser combinados como sig ue: Filtro(T) = Filtro1 (T_subtipo_1 ) Unión Filtro2(T_subtipo_2) Un grupo puede definir una tarea orientada por grupo a ser realizada por un módulo de programa. Los semánticos de un grupo pueden ser definidos para resultar en ejecución de alguna acción predefinida en cada artículo en un grupo. Mientras con otros módulos, un grupo puede ser ejecutado con un comando manual o con la ocurrencia automática de algún evento. U n grupo puede ser creado al combinar un grupo con una acción como sigue: Grupo = Grupo(T) + Acción(T) U n agente puede definir alguna acción a ser realizada con la ocurrencia de un evento predefinido, en donde el evento predefinido puede servir como un impulsador que puede activar la ejecución del agente y desempeño de la acción asociada con el agente. En términos algebraicos, Agente = Evento(T) + Acción(T) Las reglas pueden ser creadas utilizando una variedad de condiciones que pueden estar conectadas en alguna forma lógica. Dentro de cada regla, las condiciones pueden estar compuestas en una variedad de formas. Por ejemplo, los artículos que tienen una propiedad específica pueden ser descritos utilizando: <propiedad><operador de comparación><expresión> <fiitro existente> NI NGU N/TODO<objeto de relación>CONCORDANCIAS<filtro> NI NGU N/TODO<objeto de relación> DENTRO <grupo> Otras condiciones también son posibles y pueden ser utilizadas para abarcar reglas. Los componentes lógicos de EUP individuales pueden ser evaluados dentro de una aplicación. Tales evaluaciones pueden ser realizadas como tareas de antecedente y por lo tanto ser invisibles para un usuario. Adicional o alternativamente, esas tareas pueden ser explícitamente ejecutadas sujetas a una entrada de comando por un usuario. Generalmente, diferentes tipos de programas pueden ser utilizados como un grupo central de programas. Por ejemplo, un tipo central tal como un grupo derivado puede ser un programa de usuario final completo. Cuando un grupo derivado es activado o ejecutado, los comandos asociados con la lógica de la definición de grupo pueden ser ejecutados y los resultados de ia ejecución presentados. Adicionalmente, los grupos derivados pueden ser utilizados en operaciones algebraicas. Por ejemplo, dos grupos derivados pueden ser combinados como sigue: Grupo(T) = Grupo1 (T) Unión Grupo2(T) Como otro ejemplo, los agentes pueden creados para realizar acciones específicas en la ocurrencia de eventos predefinidos. Como se definió previamente, un Agentes es un Evento(T) combinado con una Acción(T). Con la ocurrencia de la porción de evento del agente, los pasos de procesamiento de la porción de acción del agente pueden ser realizados. De esta manera, la ejecución de un agente puede ser impulsada sin ninguna intervención de un usuario final. Un álgebra EUP puede ser accedida a través de una interfase de programación de aplicación (API), que puede proporcionar un medio para acceder a tipos de objeto y operaciones preescritas por el álgebra de reglas. Adicionalmente, la API puede proporcionar un grupo de componentes predefinidos tal como componentes lógicos de EU P construido previamente que pueden ser accedidos directamente como una alternativa para construir tales componentes de términos básicos. La Figura 3 es un diagrama de esquema de una jerarquía de tipo de regla 300. El esquema de la jerarquía de tipo de regla 300 puede ser utilizado para organizar tipos en uno o más componentes de funcionamiento tal como un evento, una regla, o un programa de usuario final como se describió aquí. Adicional o alternativamente, algún otro componente o una variante de uno o más de estos componentes descritos pueden ser creados de acuerdo con detalles que una implementación específica. Un evento creado, regla, o programa de usuario final puede ser utilizado solo o en combinación, como sea apropiado, para realizar alguna tarea de procesamiento de datos, dependiendo en particulares de componentes como ensamblados o definidos por un usuario final. En el ejemplo presentado en esta Figura 3, un evento puede ser un evento de regla tal como evento de regla 320 que puede impulsar la ejecución de un componente ejecutable. Una regla puede ser lógica de regla tal como lógica de regla 330 que puede definir lógica a ser aplicada a un escenario de cómputo. Un programa de regla, tal como programa de regia 340, puede ser un programa de usuario final u otro componente ejecutable. En este ejemplo específico, cada evento de regla 320, la lógica de regla 330, y ei programa de regla 340 pueden estar asociados con uno o más subcomponentes. Por consiguiente, cada uno de estos subcomponentes puede, por ejemplo, ser un tipo de artículo simple tai como un evento, o en vez de eso puede ser un tipo creado por usuario o tipo complejo tal como un grupo derivado. El componente de evento de regla 320 puede ser un tipo de base para todos los tipos de evento utilizados por agentes de plataforma de reglas creados por usuario finales, y puede ser conceptualmente abstracto y servir para proporcionar un tipo común que puede ser referenciado por cada agente. Un agente puede referirse a un caso de un componente de evento de regla, tal como el componente de evento de regla 320, que puede notificar al agente cuando ejecutar o impulsar tal ejecución. El componente de evento de regla 320 puede, por ejemplo, ser o estar asociado con un evento básico tal como evento básico 322 o un evento derivado tal como el evento filtrado 324. En un ejemplo, el evento básico 322 puede estar derivado del componente de evento y la regla 320. Un tipo de evento básico, tal como el evento básico 322, puede actuar como un punto de gancho para una aplicación para enviar un artículo de entrada a un sistema de regla para representar la descarga de un evento lógico. Por ejemplo, un evento básico puede representar tales eventos como un artículo siendo agregado a un almacenamiento de datos o un artículo de un almacenamiento de datos siendo modificado, entre otros. La emisión de un artículo de entrada a través de un artículo de evento puede comunicar el hecho de que el evento ha ocurrido y siendo un procedimiento que puede resultar en descargar otro evento. El evento filtrado 324 también puede estar derivado del componente de evento de regia 320. El evento filtrado 324 puede incluir una referencia a otro evento de regla y una referencia un caso de un tipo lógico de filtro para utilizar las descargas de filtro del evento. El evento filtrado 324 puede descargar basándose en la descarga de este componente de evento de regla de fuente, tal como el componente de evento de regla 320. Al descargar el evento de fuente, el evento filtrado 324 puede tomar un artículo de entrada en el cual el evento de fuente fue descargado y evaluar un caso de su componente lógico de filtro en el artículo de entrada. El evento filtrado 324 descargará sí y solo sí la lógica de filtro evalúa a VERDADERO. En este ejemplo, un evento filtrado tal como el evento filtrado 324 no puede surgir directamente utilizando un llamado de función de API pero más que eso solo puede surgir cuando un evento de fuente es descargado y su lógica de filtro evalúa a VERDADERO para el artículo de entrada en el cual se descargó el evento de fuente.

El componente lógico de regla 330 puede ser descrito como una regla en el sentido que el componente lógico de regla puede tener pasos de procesamiento definido que pueden causar que una o más tareas de cómputo sean realizadas por un componente que utiliza o de otra forma está asociado con el componente lógico de regla 330. El componente lógico de regla 330 puede ser, o estar asociado con, una lógica de filtro 332, una lógica de propiedad 334, una lógica de acción 336, y una lógica de asociación 338. La lógica de filtro 332, lógica de propiedad 334, lógica de acción 336, y lógica de asociación 338 pueden ser utilizadas para crear lógica de regla. La lógica de filtro 332 puede definir lógica de regla que filtra un caso de artículo dado del tipo de entrada. El tipo de salida para la lógica de filtro 332 puede ser un valor Boleano o un valor nulo. La lógica de propiedad 334 también puede definir una regla. La regla definida puede calcular un valor de un tipo especificado cuando se da un caso de artículo específico y por lo tanto puede actuar como una propiedad calculada. Para soportar este concepto, el tipo de salida de la lógica de propiedad 334 puede ser representada como un tipo de propiedad. La lógica de acción 336 puede definir una regía que puede genera una secuencia de acciones a ser realizadas cuando se da un caso de artículo específico de un tipo de salida específico. La salida de la lógica de acción 336 puede ser un objeto que es enumerable y que codifica la secuencia de acciones a ser realizadas. La lógica de asociación 338 puede ser derivada de una definición de regla y puede definir una regla que puede generar un grupo de artículos de un tipo de objetivo especificado cuando se proporciona un caso de artículo específico de un tipo de fuente. La salida de la lógica de asociación 338 puede ser un caso de un artículo enumerable que constituye el grupo de artículo. Una clase de términos descrita por esta álgebra de reglas ilustrativa incluye componentes ejecutables. Estos componentes ejecutables por sí mismos no incluyen declaraciones lógicas pero más que eso son programas de cubiertas que pueden ser creados por un usuario final y servir para unir las definiciones de lógica de regia con colecciones de entrada. Un componente ejecutable puede ser el programa de regla 340. El programa de regla 340 puede formar un tipo de base común para tipos de programa de usuario final. Una función primaria del programa de regla 340 puede ser para permitir a todos los casos el tipo de programa de usuario final, tal como grupos y agentes, para persistir, para ser capaces de ser recuperados, y para permitir ser filtrados basándose en tal tipo de entrada común. El programa de regla 340 puede ser o estar asociado con otros componentes tal como una consulta 342, un agente 344, y un grupo 346. La consulta 342 puede representar un grupo de resultado calculado y artículos que son capaces de ser evaluados de acuerdo con coacciones de una consulta. El agente 344 puede representar una acción o acciones a ser realizadas con la descarga de un evento o ocurrencia de algún suceso. El grupo 346 puede representar una acción o acciones a ser realizadas en una colección de artículos. U n usuario final puede combinar estos componentes con una amplia variedad de formas para crear un programa de regla ejecutable. La Figura 4 es un diagrama de bloque del sistema ..de un sistema de programación de usuario final 400 que incluye un sistema de archivo integrado. El sistema de programación de usuario final 400 puede derivar el soporte para sus funciones de programación de sus características específicas de este sistema de archivo importante. Específicamente, la integración de un sistema de EUP con un sistema de archivo importante apropiado puede proporcionar una base en la cual todo aspecto de un sistema de cómputo con ei que cada usuario final interactúa puede ser hecho programable. El sistema de programación de usuario final 400 incluye una interfase de usuario 410, que puede ser cualquier interfase de usuario apropiada tal como una interfase de usuario gráfica, una interfase a base de web, una interfase basada en texto, o una interfase de línea de comando, entre otros. La interfase de usuario 410 está acoplada a un diseño de regías 420 y un modulo de programación de usuario final 430. El diseño de regla 420 puede incluir todos los componentes predefinidos de un sistema de EU P, incluyendo agentes creados por usuario final, grupos, y otros componentes. El módulo de programación de usuario final 430 proporciona un mecanismo a través del cual un usuario final puede definir componentes tal como agentes. El módulo de programación de usuario final 430, junto con la ¡nterfase de usuario 420, puede proporcionar mucha, si no es que toda, la funcionalidad que un ambiente de desarrollo integrado puede proporcionar a un desarrollador de software tradicional. Tales funciones pueden inclu i r la capacidad de reutilizar componentes, componentes de versión, construir componentes al arrastrar y liberar dispositivos mecánicos gráficos , o al escribir acciones , entre otros acercamientos. U n diseño de sistema de archivo 440 puede proporcionar una representación conceptual de cómo las artículos de datos están almacenados en algún medio físico tai como un disco duro o un disco óptico, entre otros. En este ejemplo específico, un sistema de archivo que dibuja de forma pesada un concepto de diseño orientados a objeto es presentado. Más específicamente, el diseño de sistema de archivo 440 puede proporcionar una estructura de trabajo dentro de la cual los artículos pueden ser almacenados como parte de una expresión total, en donde la expresión puede ser accedida a través de una API y evaluada para producir algún resultado deseado. El diseño del sistema de archivo 440 también puede incluir un grupo de tipos en líneas que puede ser utilizado solo para persistencia y que no son utilizados como parámetros o resultados de métodos. El diseño de sistema de archivo 440 puede incluir un grupo de operadores lógicos tal como "no", "y" , y "o" . Adicionalmente, el diseño de sistema de archivo 440 puede proporcionar construcciones de programación voluminosas tal como operadores convencionales, operadores aritméticos, operadores de agregación, fecha, tiempo, y operadores de fila, y emisión de tipo, entre otros. También , los métodos y habilidades para invocar tales métodos también pueden ser proporcionados. Por ejemplo, varios constructores, destructores, accesores de valor y establecedores de valor pueden ser accedidos a través de una API. Entre las funciones de soporte que el diseño de sistema de archivo 440 puede proporcionar está en funciones de infraestructura para manejar, nombrar, compartir, almacenar, sincronizar, y buscar datos. El diseño de sistema de archivo 440 puede proporcionar todas estas capacidades para el diseño de reglas 420 y el módulo de programación de usuario final 430 para que un usuario final pueda acceder a todas las capacidades que el sistema de archivo 440 puede ofrecer como parte de construir un programa de usuario final. En los ejemplos aquí presentados, el esquema de las reglas debe conformarse a un sistema de tipo soportado por el sistema de archivo. También, la superficie de API completa para los conceptos de programación de usuario final siguen los modelos estándares de las APls de sistema de archivo. Un efecto lateral de estas selecciones de diseño es que las aplicaciones de interfase de usuario genéricas que trabajan contra los artículos de sistema de archivo trabajarán también contra artículos de programación de usuario final. Lógicamente, pueden existir dos niveles de esquema en el diseño de sistema de archivo 440. En el primer nivel puede haber un esquema para el código de desarrollador. Este esquema de código de desarrollador puede definir tipos de artículos y aspectos de comportamiento de aquellos artículos. Al utilizar este nivel de esquema, otros desarrolladores comparten abstracciones de datos con una estructura común para referencia. En el segundo nivel puede haber un esquema para una lógica de usuario final. Este nivel de lógica de usuario final puede ser utilizado para proporcionar una estructura de trabajo para reglas de usuario final . Los sistemas de tipo tanto para usuarios finales como para el sistema de archivo 440 también pueden estar cercanamente alineados. Específicamente, en este ejemplo, una jerarquía de tipo de tipos de usuario final puede ser una simplificación de una jerarquía de tipo de tipos del sistema de archivo . Algunos tipos en la jerarquía del sistema de archivo potencialmente pueden ser omitidos debido a que son irrelevantes para usuarios finales. Adicionalmente, el delineado de unión puede ser creado para todo tipo de usuario final para un tipo de sistema de archivo importante. Unos delineados o uniones pueden ser utilizados para unir un espacio entre el nivel de usuario final y el nivel del sistema de archivo. Las uniones pueden servir para múltiples propósitos, incluyendo la capacidad de localizar nombres de elementos de esquema de usuario final. Específicamente, en este ejemplo, un enlace puede ser una regla. En un caso ilustrativo trivial , el enlace puede ser una regla con una declaración individual cuya condición siempre es verdadera y cuyo resultado es una propiedad importante específica en el tipo de desarrollador. Los enlaces también pueden proporcionar un nivel de dirección entre el esquema del nivel de desarroilador y el esquema de nivel de usuario final. Varias políticas de control de acceso pueden ser aplicados aquí dependiendo en una implementación específica. Por ejemplo , los desarrolladores de sistema de archivo pueden ser permitidos para definir cuales propiedades de tipos que crean los desarrolladores serán accesibles a usuarios finales. Alternativamente, los usuarios finales pueden ser proporcionados con la capacidad de definir que propiedades de tipos creados por desarrollador desea el usuario final acceder. Alguna combinación de estos dos acercamientos también es posible. La Figura 5 es un diagrama de bloque de sistema de un sistema de programación de usuario final 500 que incluye un sistema de archivo integrado. El sistema de programación de usuario final 500 puede ser utilizado para adaptar aplicaciones que pueden correr en un espacio controlado o creado por un usuario final . Adicional o alternativamente, el sistema de programación de usuario final 500 puede ser utilizado para crear componentes que modifican el comportamiento de aplicaciones que operan en otros espacios tal como procedimiento de sistema o malignos, entre otros. El sistema de programación de usuario final 500 incluye una interfase de usuario 510 , que puede ser cualquier interfase de usuario apropiada tal como un ¡nterfase de usuario gráfica, una interfase a base de web, una interfase a base de texto, o una interfase de línea de comando, entre otros. También posibles son las interfases especializadas tal como interfase Braille para interfases ciegas y de audio, entre otros. La interfase de usuario 510 está acoplada a un diseño de aplicación 520, que puede incluir tales aplicaciones controladas por usuario final tal como clientes de correo electrónico, procesadores de palabra, programas de hoja de cálculo, y navegadores web, entre otros. Adicional o alternativamente, el diseño de aplicación 520 puede incluir los procedimientos así llamados sistemas que proporcionan servicios a otros programas de computadora en ejecución tai como revisiones de sistema de nombre de dominio (DNS) y capacidades en red, entre otros. Un diseño de reglas 530 está acoplado al diseño de aplicación 520. El diseño de reglas 530 proporciona componentes de programación de usuario final y soporte para el diseño de aplicación 520 y puede ser implementado en una forma similar al diseño de reglas 420 de la Figura 4. También, un módulo de programación de usuario final 540 está acoplado tanto al diseño de reglas 530 como a la ¡nterfase de usuario 540. El modulo de programación de usuario final 540 puede proporcionar acceso al diseño de reglas 530 y la capacidad de crear nuevas reglas, tanto como el módulo de programación de usuario final 430 de la Figura 4. Un sistema de archivo 550 puede proporcionar una estructura de trabajo de almacenamiento en la cual las reglas del diseño de reglas 530 y otros programas de usuario final que puede ser creado por el módulo de programación de usuario final 540 pueden ser accedidos o de otra forma utilizados por el diseño de aplicación 520. Cualquier sistema de archivo adecuado puede ser utilizado o adaptado para utilizarse en este contexto. Un sistema de archivo que tiene una API que puede estar integrada con o delineada a una API para las funciones de programación de usuario final está específicamente adaptado para este uso. En operación, un usuario final puede interactuar con el sistema de programación de usuario final 500 a través de la interfase de usuario 510. El usuario final puede utilizar el módulo de programación de usuario final 540 para crear reglas, agentes, o grupos, entre otras cosas, que pueden agrados al diseño de reglas 530. El usuario final también puede acceder a aplicaciones del diseño de aplicación 520 a través de la 'mterfase de usuario 510. Cuando un evento u otro objeto de impulso causa que una regla se active, los mensajes pueden ser pasados entre el diseño de aplicación 520 y el diseño de reglas 530. Dependiendo en las especificaciones de la activación de regla, estos mensajes pueden ser sincrónicos o asincrónicos. Cualquiera que sea la regla o reglas cuando son activadas después pueden ejecutarse de acuerdo con su diseño y hacer cualquiera de las modificaciones que son apropiadas en el nivel de sistema de archivo 550 al utilizar porciones delineadas o limitadas de ía API def sistema de archivo. La Figura 6 es un diagrama de bloque del sistema de un sistema de programación de usuario final 600 que puede ser utilizado para crear módulos de programa definidos por usuario final que maneja información electrónica almacenada en un sistema de archivo. Este módulo de programa automáticamente puede aplicar reglas creadas por un usuario final para manipular información almacenada en un sistema de archivo de acuerdo con instrucciones específicas de un usuario final. Tales instrucciones pueden incluir aplicar filtros para agrupar información o para realizar tareas de manejo de información específicas, tal como tarea de organización, con la ocurrencia de algún evento predefinido. El sistema de programación de usuario final 600 incluye un módulo de programación de usuario final 610 que proporciona acceso a funciones de soporte de programación de usuario final tal como creación de regla o modificación y definición de evento. El módulo de programación de usuario final 610 específicamente puede ser implementado como cualquiera de los módulos de programación de usuario final previamente descrito en conjunto con otras figuras. Los programas de usuario final creados utilizando el módulo de programación de usuario final 610 pueden ejecutarse automáticamente, como con un programa conducido por evento, o pueden ser invocados por un comando específico desde el usuario final. U na interfase de computadora humana 620 puede proporcionar acceso a funciones y características del módulo de programación de usuario final 610. Se puede utilizar una variedad de componentes para implementar la interfase de computadora humana 620 dependiendo de las necesidades y deseos de implementación específicos. Por ejemplo, la interfase de computadora humana 620 puede ser implementada como una interfase de usuario gráfica, tal como una interfase de usuario gráfica de un sistema operativo. Alternativamente, la interfase de computadora humana 620 puede estar basada en un navegador web, puede ser una interfase a base de texto tal como una línea de comando, puede ser una interfase a base de tacto de Braille, o puede ser una interfase a base de lenguaje, entre otros. Una plataforma de regla 630 puede incluir los programas definidos por usuario final creados utilizando el módulo de programación de usuario final 610. Adicionalmente, los componentes de bloque de construcción que pueden ser utilizados para crear programas de usuario final pueden estar incluidos en la plataforma de reglas 630. El módulo de programación de usuario final 610 y la interfase de computadora humana 620 ambas pueden crear acceso a la plataforma de reglas 630 para permitir a un usuario final crear, modificar, eliminar, e invocar la ejecución de programas de usuario final en la plataforma de reglas 630. La plataforma de reglas 630 está acoplada al sistema de archivo 640. El sistema de archivo 640 puede ser implementado como cualquier sistema de archivo apropiado que puede soportar organización de datos y tareas de recuperación. Específicamente, el sistema de archivo 640, junto con una API que proporciona acceso a funciones del sistema de archivo 640, puede ser acoplado con una API de la plataforma de regla 630 para que las funciones de la plataforma de regla 630 puedan ser delineadas o limitadas para funciones del sistema de archivo 640. La integración de la plataforma de regla 630 con el sistema de archivo 640 en esta forma expone efectivamente las funciones del sistema de archivo 640 a un usuario final para que el usuario final pueda utilizar funciones del sistema de archivo para varias tareas de cómputo incluyendo organización de información y tareas de procedimiento automatizadas, entre otros. El acceso a las funciones del sistema de archivo 640 a través del usuario final es a través de la plataforma de reglas 630, proporcionando un diseño de protección para el sistema de archivo 640 desde acciones inadvertidas o malignas que pueden corromper o de otra forma dañar el sistema de archivo. Por ejemplo, una función específica tal como mover un archivo desde una ubicación física en un dispositivo de almacenamiento a otra ubicación sin cambiar una ubicación lógica del archivo puede permanecer no delineado o limitado a una función del módulo de programación de usuario final 610 o la plataforma de regla 630, previniendo al usuario final de acceder a esa función. El sistema de archivo 640 puede imponer un esquema de organización de archivo lógico en uno o más dispositivos de almacenamiento persistentes 650, 660, 670 (PS). Los dispositivos de almacenamiento persistentes 650, 660, 670 pueden ser unidades de disco duro, unidades ópticas, dispositivos de memoria instantánea, u otros dispositivos de almacenamiento apropiados, y pueden operar independientemente como discos separados que cada uno utiliza un sistema de archivo. Adicional o alternativamente, los dispositivos de almacenamiento persistentes 650, 660, 670 pueden ser porciones lógicas en una o más unidades de disco físico. En esta configuración, un usuario final puede estar conciente del hecho que existen múltiples discos o divisiones que proporcionan espacio de almacenamiento. Los dispositivos de almacenamiento persistentes 650, 660, 670 también pueden estar integrados como parte de un volumen de almacenamiento lógico individual, como con una orden redundante de discos independientes (RAID). Cuando se configura como un orden de RAID, en los dispositivos de almacenamiento persistentes 650, 660, 670 pueden ser accedidos como una entidad individual que utiliza un sistema de archivo individual. También, los dispositivos de almacenamiento persistentes 650, 660, 670 pueden ser parte de una red de área de almacenamiento (SAN) o algún otro sistema de almacenamiento. En operación, el sistema de programación de usuario final 600 puede funcionar como sigue. Un usuario final puede acceder al módulo de programación de usuario final 610 a través de la interfase de computadora humana 620 para crear un programa de usuario final. El programa de usuario final reside en la plataforma de regla 630 hasta que se invoca la ejecución a través de un comando del usuario final o con la ocurrencia de un evento específico o predefinido. La plataforma de reglas 630 envía un mensaje al sistema de archivo 640 que solicita que el sistema de archivo 640 realice alguna tarea de manipulación de información en los dispositivos de almacenamiento persistentes 650, 660, 670. Con el término exitoso o falla de la tarea solicitada y en un ambiente de envío de mensaje sincrónico, el sistema de archivo 640 envía un mensaje a la plataforma de reglas 630 para informar al programa de usuario final del resultado de la tarea solicitada. Alternativamente, como con un sistema de envío de mensaje asincrónico, el sistema de archivo 640 puede realizar o intentar realizar la tarea solicitada sin enviar un mensaje de respuesta a la plataforma de reglas 630. La información sobre la acción solicitada es presentada en la interfase de computadora humana 620 para verse por el usuario final. La Figura 7 es un diagrama de bloque de sistema de un sistema de programación de usuario final en red 700 que puede ser utilizado para crear módulos de programa definidos por usuario final que manejan información de electrónica almacenada en un sistema de archivo remoto, en donde la información puede ser accedida en una red. Los módulos de programa de usuario final en red automáticamente pueden aplicar reglas creadas por un usuario final para acceder o manipular información almacenada en el sistema de archivo remoto. El sistema de programación de usuario final en red 700 incluye un módulo de programación de usuario final 710 que puede proporcionar acceso a funciones de soporte de programación de usuario final como creación de regla, modificación de reglas y definición o identificación de eventos de impulso. El módulo de programación de usuario final 710 específicamente puede ser implementado como cualquiera de los módulos de programación de usuario final previamente descritos en conjunto con otras figuras. Consistente con tal implementación, los programas de usuario final creados utilizando el módulo de programación de usuario final 710 puede ejecutarse automáticamente, como con un programa dirigido por evento, o puede ser invocado por un comando específico desde el usuario final. Una plataforma de reglas 720 puede incluir los programas definidos por usuarios final creados utilizando el módulo de programación de usuario final 710. Adicionalmente, los componentes de bloque de construcción que pueden ser utilizados para crear programas de usuario final pueden estar incluidos en la plataforma de reglas 720. El módulo de programación de usuario final 710 y una interfase de usuario 730 ambos pueden acceder a la plataforma de reglas 720 para permitir a un usuario final crear, modificar, eliminar, e invocar la ejecución de programas de usuario final en la plataforma de reglas 720. La plataforma de reglas 720 también pueden proporcionar funciones en red u otra comunicación, tal como el paso de mensaje, entre programas de usuario final u otros componentes de la plataforma de reglas 720 y el sistema de archivo 740. Para hacer eso, ia plataforma de reglas puede utilizar una red 750. La red 750 puede ser cualquier red alámbrica o inalámbrica asociada, puede ser una red de área local (LAN), una red de área amplía (WAN), un intranet, o Internet, entre otros. Consiste con esta implementación, la plataforma de reglas 720 puede incluir componentes en red tal como grupos de comunicación como un protocolo de control de transferencia/grupo de protocolo de Internet (TCP/IP), entre otros. Alternativamente, la plataforma de reglas 720 simplemente puede tener acceso a tales funciones proporcionadas por otro componente tal como un sistema operativo o una aplicación en red. El sistema de archivo 740 puede imponer una jerarquía de organización en un dispositivo de almacenamiento remoto 760. El dispositivo de almacenamiento remoto puede ser un dispositivo de almacenamiento persistente tal como una unidad de disco o cualquier otro tipo de dispositivo de almacenamiento persistente, específicamente incluyendo tipos mencionados y descritos en conjunto con otras figuras. Adicional o alternativamente, el dispositivo de almacenamiento remoto puede ser una base de datos u otro tipo de almacenamiento de datos que puede proporcionar acceso y características de manipulación en una forma similar a esa de un sistema de archivo. En operación, el sistema de programación de usuario final en red 700 puede funcionar como sigue. Un usuario final puede acceder al módulo de programación de usuario final 710 a través de la interfase de usuario 730 para crear uno o más programas de usuario final. Estos programas de usuario final residen en la plataforma de reglas 720 hasta que se invoca a la ejecución a través de un comando del usuario final o con la ocurrencia de un evento específico o predefinido. La plataforma de reglas 720 utiliza la red 750 para pasar un mensaje al sistema de archivo 740 solicitando que el sistema de archivo 740 realice alguna tarea relacionada con información en conexión con el dispositivo de almacenamiento remoto 760. Con el término exitoso o falla de la tarea solicitada, el sistema de archivo 740 utiliza la red 750 para pasar un mensaje a la plataforma de reglas 720 para informar al programa de usuario final del resultado de la tarea solicitada. La información sobre el resultado es presentada en interfase de usuario 730 para verse por el usuario final. Con referencia a las Figuras 8-9, los cuadros de flujo de acuerdo con varios métodos o procedimientos son presentados. Mientras, para propósitos de simplicidad de explicación, una o más metodologías aquí mostradas, por ejemplo, en la forma de un cuadro de flujo, son mostradas y descritas como una serie de actos, se debe entender y apreciar que ni los métodos y procedimientos ilustrados y descritos ni ninguno de los componentes con los cuales se pueden utilizar tales métodos o procedimientos necesariamente están limitados por el orden de actos, mientras algunos actos pueden ocurrir en un orden diferente y/o concurrentemente con otros actos de esos mostrados y descritos aquí. Por ejemplo, aquellos expertos en la técnica entenderán y apreciarán que una metodología podría alternativamente ser presentada como una serie de estados o eventos interrelacionados, tal como en un diagrama de estado. Además, no todos los actos ilustrados pueden ser requeridos para implementar una metodología o procedimiento. La Figura 8 es un diagrama de flujo de un procedimiento 800 que puede ser utilizado en conjunto con componentes que han sido descritos y mencionados aquí con referencia a otras figuras. La ejecución del procedimiento 800 comienza en un bloque de INICIO 810 y continúa al bloque de procedimiento 820 en donde la interfase de CUP es accedida por un usuario final. Después el usuario final selecciona un evento de impulso en el bloque de procedimiento 830. Por ejemplo, el evento de impulso puede ser un orden de un mensaje de correo electrónico, creación del documento, o algún otro evento. En el bloque de procedimiento 840, un grupo de acciones, que puede incluir una pluralidad de acciones, una acción individual o ninguna acción, es definido. Estas reacciones pueden ser tales cosas como mover un archivo a una ubicación específica, responder automáticamente a un mensaje de correo electrónico, o convertir un archivo de un formato a otro, entre otros. El grupo de acciones está limitado al evento en el bloque de procedimiento 850. La base de regla es actualizada con el nuevo enlace en el bloque de procedimiento 860. El procedimiento concluye en el bloque de FI N 870. La Figura 9 es un diagrama de flujo del procedimiento 900 que puede ser utilizado en conjunto con componentes que han sido mencionados y descritos aquí con referencia a otras figuras. El procedimiento comienza en el bloque de IN ICIO 905 y continúa al bloque de procedimiento 910 en donde la plataforma de cómputo descarga un evento. En el bloque de procedimiento 915 el componente de EUP detecta el evento. El procedimiento continúa en el bloque de procedimiento 920 en donde ef EUP accede al almacenamiento de datos de regla. En el bloque de decisión 925 se hace una determinación sí existe un enlace de regla para el evento detectado. Si sí existe, el procedimiento continúa al bloque de procedimiento 930 en donde se obtienen las acciones definidas por usuario final. En el bloque de procedimiento 935, los procedimientos son iniciados o activados para realizar las acciones definidas por usuario final. Los mensajes de término son recibidos desde esos procedimientos en el bloque de procedimiento 940. Se hace una determinación si todos los procedimientos fueron completados exitosamente en el bloque de decisión 945. Sí es así, se crea un indicador exitoso general en 955. Si no es así, se crea un mensaje de error general en el bloque de procedimiento 950. El procedimiento concluye tanto del bloque de procedimiento 950 como del bloque de procedimiento 955 en el bloque de FIN 960. Simílarmente, si la determinación hecha en el bloque de decisión 925 es no, el procedimiento concluye en el bloque de FIN 960. La Figura 10 es un diagrama de flujo de un ciclo de vida de información 1000. El ciclo de vida de información generalmente puede definir la existencia de un artículo de datos en un sistema de cómputo. Tal existencia puede comenzar cuando un usuario primero crea u obtiene un artículo específico de datos y termina cuando el usuario elimina el artículo o de otra forma descarta los datos. El ciclo de vida de información 1000 incluye una fase de organización 1010, que representa un punto cuando el usuario final ha creado u obtenido un artículo de información y desea tener el artículo de información persistida y permanecer disponible para el. Existen al menos dos técnicas que pueden ser utilizadas para organizar datos.

Con referencia a la primera técnica, las propiedades de un artículo pueden ser asignadas con valores. Por ejemplo, un artículo puede ser proporcionado con un nombre o alguna otra descripción que puede ser almacenada como metadatos o un atributo, entre otras cosas. Con referencia a la segunda técnica, se pueden asignar relaciones de un artículo. La asignación de revelaciones puede ayudar en la ubicación de artículos a través de una navegación manual o por búsqueda. En particular, ciertas relaciones pueden estar asociadas con semánticos de organización especiales en aplicaciones. Por ejemplo, una relación de contención de carpeta puede ser una forma jerárquica común con la cual organizar información de acuerdo con un tema común. A las propiedades y relaciones se les pueden asignar valores en al menos dos formas diferentes. Los valores reales pueden ser materializados y mantenidos con los datos de artículo. Adicional o alternativamente, los valores pueden ser calculados de otros datos con la demanda. En este caso una definición del cálculo a ser realizado para obtener los datos puede ser almacenada como metadatos. Los mecanismos calculados para organización de datos son apropiados cuando las reglas para la organización de datos son bien definidas, fácilmente expresables, y basándose completamente en información disponible. Los mecanismos calculados también pueden clasificarse para tratar con grandes volúmenes de datos. Los mecanismos materializados son apropiados cuando la lógica de organización de datos ño puede ser expresada fácilmente o estar basada en información que no puede ser capturada fácilmente tal como contenido o información de contexto. Los programas de usuario final pueden definir propiedades calculadas y relaciones. Tales programas también pueden ser utilizados para mantener automáticamente propiedades materializadas y relaciones. Una fase de almacenamiento 1020 puede indicar que un usuario está guardando un artículo de información en un formato persistente que puede ser accedido más tarde. Los formatos persistentes que pueden ser utilizados incluyen archivos y objetos, entre otros. Los detalles de tales formatos persistentes pueden variar de acuerdo con detalles particulares de un sistema de archivo dentro del cual el formato persistente es almacenado. Por ejemplo, tanto una unidad de disco duro como un disco óptico pueden ser utilizados como dispositivos de almacenamiento persistentes. Sin embargo, los formatos de sistema de archivo para la unidad de disco duro varían ampliamente de formatos de sistema de archivo tai como ISO 9660 que puede ser utilizado en discos ópticos. Una fase de encuentro 1030 puede indicar un periodo cuando un usuario final desea recuperar información almacenada en algún formato persistente. El término encontrar puede incluir cualquiera actividad que puede causar que un artículo sea identificado como disponible para el usuario final para que actúe con ese. Existen al menos dos formas en la cual un usuario final puede encontrar datos. En la primera, el usuario final puede navegar o interactuar con los datos. De esta manera, el usuario final comienza con algún punto de inicio, tal como un directorio de inicio o referencia. Las relaciones entre los artículos de datos pueden proporcionar grupos para navegar o atravesar artículos en un almacenamiento de datos. Un ejemplo específico es navegar a través de un árbol de directorio jerárquico. En el segundo aspecto, el usuario final puede ejecutar una consulta. Una consulta definida por un usuario final puede describir un subgrupo de artículos en un almacenamiento de datos que puede concordar con alguna descripción declarativa. Al utilizar el tercer acercamiento, un evento puede ser utilizado a través del usuario final para encontrar un artículo. Un evento de ese tipo puede ser utilizado para desviar ia atención a algún otro artículo específico. Por ejemplo, agregar un archivo a un directorio puede ser un evento que desvía la atención al archivo agregado. Cada uno de estos aspectos tiene puntos fuertes y débiles. Los mecanismos a base de consulta pueden ser utilizados cuando la lógica utilizada para encontrar artículos es bien definida y fácilmente expresada en términos de conceptos modelados en el almacenamiento de datos. La ejecución de consultas puede ser clasificable y eficiente, sin embargo, la ejecución de consulta también puede ser computacionalmente intensiva, incluso cuando se utiliza un mecanismo de consulta eficiente relativamente. Los mecanismos de navegación pueden ser utilizados para proporcionar flexibilidad pero requieren más intervención del usuario que las consultas. Adicionalmente, los mecanismos de navegación no necesariamente clasifican así como los mecanismos de consulta tratan con grandes grupos de datos. Los mecanismos dirigidos por evento son adecuados para casos en donde una meta es encontrar datos apropiados en un punto apropiado en el tiempo sin dirigir la intervención del usuario. Existen al menos dos clases básicas de eventos. Primero, un evento de aplicación puede ser causado por la ejecución de una aplicación específica o grupo de aplicaciones. Segundo, un evento de cambio de datos puede ser causado por cualquier actividad que cambia datos, independientes de la aplicación que causó el cambio en los datos. Un evento de cambio de datos puede ser surgido a través de un sistema de manejo de datos. Los tipos particulares de eventos pueden ser surgidos ya sea sincrónicamente o asincrónicamente. Para eventos sincrónicos, una aplicación o sistema espera una respuesta para el evento antes de continuar. Para eventos asincrónicos, no se necesita ninguna respuesta antes de que ia aplicación de surgimiento pueda continuar procedimiento con su tarea. Una fase de uso 1040 puede indicar que el usuario final ha encontrado y recuperado los datos y está listo para utilizarlos o de otra forma actúa con los datos. Las acciones básicas en los artículos pueden ser proporcionadas a través de aplicaciones que exponen los artículos a un usuario final. Algunas acciones pueden ser intrínsecas para un tipo de artículos. Por ejemplo, una acción puede ser utilizada para establecer una propiedad de un artículo. Otras acciones pueden ser intrínsecas para la aplicación que puede utilizar el artículo. Un ejemplo aquí es una acción para presentar el texto de un artículo de mensaje en un color específico. Las acciones calculadas pueden ser construidas desde otras aplicaciones que utilizan al menos uno de los siguientes mecanismos. Primero, las acciones en relaciones pueden ser utilizadas. En este esquema, una acción en artículo puede ser definida para incluir acciones en objetivos o las relaciones de los artículos. Por ejemplo, cuando se utiliza una relación para definir un grupo de artículos tal como un grupo de carpeta, las acciones calculadas pueden especificar acciones uniformes en todos los miembros del grupo. Este procedimiento puede ser denominado como un grupo. También se pueden utilizar acciones condicionales. Las acciones existentes pueden ser combinadas con lógica condicional para definir una acción calculada condicional. Por ejemplo, si un documento está marcado como confidencial, una bandera de prioridad puede ser establecida para indicar prioridad superior. Si el documento no está marcado como confidencial, una bandera de prioridad puede ser establecida para indicar que el documento tiene una prioridad normal. Además, una secuencia de acción puede ser creada para que se coloquen múltiples acciones en una lista que deben ser secuencialmente ejecutadas. Por ejemplo, se puede utilizar una secuencia de acción para imprimir un documento y después eliminar el documento. Las acciones tal como ésta pueden tener efectos coíaterales que pueden crear situaciones en donde el orden de acciones debe ser determinativo con el fin de que el comportamiento definido sea sensible. Con el fin de proporcionar contexto adicional para implementar varios aspectos de la invención sujeta, las Figuras 1 1 -12 en la siguiente discusión pretenden proporcionar una breve descripción general de un ambiente de cómputo adecuado dentro de! cual varios aspectos de la invención sujeta pueden ser implementados. Mientras la invención ha sido descrita anteriormente en el contexto general de instrucciones ejecutables por computadora de un programa de computadora que corre en una computadora local y/o computadora remota, aquellos expertos en la técnica reconocerán que la invención también puede ser implementada en combinación con otros módulos de programa. Generalmente, los módulos de programa incluyen rutinas, programas, componentes, estructuras de datos, etc. , que realizan tareas particulares y/o implementan tipos de datos abstractos particulares. Aquellos expertos en la técnica apreciarán que los métodos inventivos pueden ser practicados con otras configuraciones del sistema de computadora, incluyendo procesador individual o sistemas de computadora de multiprocesador, minicomputadoras, macrocomputadoras, así como computadoras personales, dispositivos de cómputo portátiles, electrónico a base de microprocesador y/o programabie para el consumidor, y similares, cada uno que puede comunicar operativamente uno con uno o más dispositivos asociados. Los aspectos ilustrados de la invención también pueden ser practicados en ambientes de cómputo distribuidos en donde se realizan ciertas tareas a través de dispositivos de procesamiento remotos que están conectados a través de una red de comunicaciones. Sin embargo, algunos, si no es que todos los aspectos de la invención pueden ser practicados en computadoras aisladas. En un ambiente de cómputo distribuido, los módulos de programa pueden estar localizados tanto en dispositivos de almacenamiento de memoria locales y/o remotos. Además, los componentes mencionados y descritos o procedimientos pueden ser implementados como un método, aparato, o artículo de fabricación que utiliza programación estándar y/o técnicas de ingeniería para producir software, firmware, hardware, o cualquier combinación de los mismos para controlar de esa forma una computadora para implementar los componentes o procedimientos mencionados y descritos. El término, "artículo de fabricación" como se utiliza aquí pretende abarcar un programa de computadora accesible desde cualquier dispositivo legible por computadora, vehículo, o medios. Por ejemplo, los medios legibles por computadora pueden incluir pero no están limitados a dispositivos de almacenamiento magnéticos, por ejemplo, disco duro, disco flexible, y filas magnéticas, entre otros, discos ópticos tal como discos compactos (CDs) y discos versátiles digitales (DVDs) , entre otros, tarjetas inteligentes, dispositivo de memoria instantánea similares, tarjetas, cartuchos, y unidades de clave, entre otros. Adicionalmente, se debe apreciar que una onda de vehículo puede ser empleada para transportar datos electrónicos legibles por computadora tal como aquellos utilizados para transmitir y recibir correo electrónico o un acceso a una red tal como Internet o una red de área local (LAN). Por supuesto, aquellos expertos én la técnica reconocerán que muchas modificaciones menores pueden ser hechas a esta configuración. Se debe apreciar que aunque los ejemplos específicos presentados pueden describir o ilustrar sistemas o métodos que están basados en búsquedas de contenidos de sistemas de archivo en una computadora personal, la aplicación no está limitada a este dominio. Por ejemplo, los componentes y métodos mencionados , y descritos también pueden ser empleados en una intranet, una red privada, o Internet. Adicional o alternativamente, los componentes y métodos mencionados y descritos pueden ser utilizados como parte de una red de área de almacenamiento (SAN). Aquellos expertos ordinarios en la técnica reconocerán rápidamente que los componentes y métodos mencionados y descritos pueden ser utilizados para buscar y manipular otros tipos de información , incluyendo páginas web, consultas de base de datos, información fotográfica, e información de audio o vídeo, entre otros. La programación de usuario final (EUP) puede ser descrita como una capacidad de un usuario final para controlar cada uno y todo aspecto de comportamiento de una aplicación de software céntrica de información. Los principios de EUP y componentes pueden ser utilizados para confeccionar y personalizar tareas de procedimiento de información automatizadas realizadas por una aplicación de software o múltiples aplicaciones bajo control de un usuario final . Al menos existen tres formas interrelacionadas para que los principios de EU P y componentes ayuden a los usuarios. En la primera forma, un número potencialmente grande pasos de procedimiento que un usuario final normalmente tendría que realizar manualmente puede ser automatizado de acuerdo con necesidades o deseos específicos de un usuario final. Por ejemplo, un usuario final que trabaja con una gran colección de imágenes digitales almacenadas en una resolución muy alta puede desear crear versiones de resolución baja de estas imágenes para usarse en una página web. Para hacer eso manualmente, el usuario final típicamente tendría que abrir cada imagen individual en un programa de edición , crear una copia de resolución baja de acuerdo con varios establecimientos de programa, y guardar la versión de resolución ¡nferior con un nuevo nombre de archivo en una nueva ubicación . U n módulo de EU P puede ser creado para realiza r estas tareas automáticamente con la adición de una nueva imagen para un directorio específico. En la segunda forma de emplear principios de EU P, un módul o de EU P puede realizar una cantidad importante de cálculo para e l usuario final. Por ejemplo, muchas tareas de búsqueda comúnmente son muy calculablemente intensivas, y un módulo de EUP puede realizar automáticamente búsquedas (y otras tareas calculablemente costosas) y reportar resultados de la búsqueda al usuario final.

Adicional o alternativamente, un módulo de EUP puede realizar tales tareas cuando se invoca o ejecuta específicamente por un usuario final. En la tercera forma, un módulo de EUP puede funcionar automáticamente con la intervención del usuario final, con eso permitiendo a un usuario final enfocar su atención en otras tareas en vez de una tarea de cómputo específica. Este funcionamiento automático puede aumentar la productividad de un usuario final a liberar al usuario final de ser realizados manualmente, las tareas intensivas de tiempo tal como almacenar archivos electrónicos y agrupar tales archivos en colecciones lógicas. Los conceptos y componentes de EU P presentados aquí proporcionan una plataforma generalizada y flexible con la cual una gran variedad de implementaciones puede ser creada. Algunas implementaciones posibles pueden proporcionar una plataforma voluminosa que puede ser utilizada para soportar tareas de programación de usuario final a través de una plataforma completa para que toda aplicación de usuario pueda acceder y beneficiarse de funciones de programación de usuario final. Otras implementaciones posibles pueden soportar tal funcionalidad solo para una aplicación individual, y otras implementaciones caerán en alguna otra parte entre estos dos extremos. Aquellos expertos ordinarios en la técnica reconocerán rápidamente a partir de una lectura de prescripción que son posibles muchas alteraciones y variaciones. Los programas de usuario final pueden definir todas las formas de acciones calculadas presentadas en los ejemplos de aquí, así como otros casos. Una forma notable incluye la asociación de una acción con un evento que puede ser denominado como un agente. Un agente que involucra eventos sincrónicos puede incluir dos casos especiales de interés. En el primer caso, tal agente puede proporcionar la adaptación de aplicación al realizar acciones que pueden ser intrínsecas para la aplicación. Por ejemplo, una aplicación de correo puede surgir con un evento sincrónico antes de enviar un mensaje de correo. Una acción de agente resultante puede ser para anexar una falla de marca al mensaje. Cuando la acción del agente es una acción condicional, el agente puede elegir un archivo de marca basándose en las propiedades del mensaje. En un segundo caso, las coacciones en los datos están involucradas. Un agente de coacción de datos puede actuar para aceptar o negar un cambio a los datos que causó que un evento surgiera. Por ejemplo, un cambio en la propiedad de un archivo puede causar que surja un evento. El evento surgido puede impulsar una acción del agente que evalúa el cambio de propiedad. Basándose en el crjterio tal como identidades del propietario actual del archivo, el nuevo propietario del archivo, y el usuario que efectúa el cambio, el agente de coacción de datos puede aceptar o negar el cambio en la información de propiedad. Son posibles evaluaciones más complejas con el uso de componentes más sofisticados. Tales componentes pueden incluir varios componentes de inteligencia artificial que pueden identificar o concordar patrones o realizar varias tareas de clasificación. Los componentes de inteligencia artificial apropiados que pueden ser utilizados incluyen redes neurales y máquinas de vector de soporte, entre otros. Los componentes mencionados y descritos (por ejemplo, un agente creado para realizar tareas de filtrado o manejo) pueden emplear estos varios esquemas a base de inteligencia artificial para llevar a cabo tareas programadas. Por ejemplo, la identificación de un patrón de datos complejo y una clasificación de un nuevo dato como perteneciente a un grupo de datos que tiene el patrón de datos complejo puede ser llevada a cabo por una red neural, un componente de procedimiento a base de reglas, o un SVM. Un clasificador es una función que delinea un vector de atributo de entrada, X = (X?,x.2, 3,x4, --- xn), para una confidencia de que la entrada pertenece a una clase, eso es f(X) = confidencia (clase). Tal clasificación puede emplear un análisis a base de probabilística y/o estadística (por ejemplo, al factorizar en las utilidades de análisis y costos) para pronosticar o inferir una acción que un usuario desea que sea automáticamente realizada. En el caso de un sistema de programación de usuario final, los artículos de datos pueden ser clasificados al examinar atributos de aquellos artículos de datos. La máquina de vector de soporte (SVM) es un ejemplo de un clasificador que puede ser empleado. El SVM opera al encontrar una hipersuperficíe en el espacio de entradas posibles, que la hipersuperficie intenta dividir al impulsar el criterio de los eventos de no impulso. De forma intuitiva, esto hace que la clasificación corrija los datos de prueba que están cerca, pero que no son idénticos a los datos de entrenamiento. Otros acercamientos de clasificación de modelo dirigido y no dirigido incluyen, por ejemplo, Bayes naturales, redes bayesianas, árboles de decisión, y modelos de clasificación probabilística proporcionando patrones diferentes de independencia que pueden ser empleados. Las clasificaciones como se utilizan aquí también son inclusivas de regresión estadística que es utilizada para desarrollar modelos de prioridad. Como se apreciará rápidamente de la aplicación sujeta, los componentes mencionados y descritos aquí pueden emplear clasificadores que son explícitamente entrenados (por ejemplo, por datos de un entrenamiento genérico) así como implícitamente entrenados (por ejemplo, al observar comportamientos de usuario, recibir información extrínseca, ... ). Por ejemplo, las SVMs están configuradas por una fase de aprendizaje o entrenamiento dentro de un constructor de clasificador y módulo de selección de característica. De esa forma, el clasificador(es) puede ser utilizado para realizar automáticamente un número de funciones incluyendo pero no limitándose a determinar si un dispositivo debe ser enviado con datos. La Figura 1 1 es un diagrama de bloque esquemático de un ambiente de cómputo de muestra 1100 con el cual los componentes mencionados y descritos y los procedimientos pueden interactuar. El sistema 1 100 incluye uno o más clientes(s) 1 1 10. El cliente(s) 1 1 10 puede ser hardware y/o software (por ejemplo, filas, procedimientos, dispositivos de cómputo). El sistema 1100 también incluye uno o más servidor(es) 1120. El servidor(es) 1120 puede ser hardware y/o software (por ejemplo, filas, procedimientos, dispositivos de cómputo). Los servidores 1 120 pueden alojar filas de procedimiento para realizar transformaciones al emplear los componentes y procedimientos descritos y mencionados, por ejemplo. Un medio posible de comunicación entre un cliente 1 1 10 y un servidor 1120 puede estar en la forma de un paquete de datos adaptado para ser transmitido entre dos o más procedimientos de computadora. El sistema 1 100 incluye una estructura de trabajo de comunicación 1 140 que puede ser empleado para facilitar comunicaciones entre el cliente(s) 1 1 10 y el servidor(es) 1 120. El cliente(s) 1 1 10 está operativamente conectado a uno o más almacenamiento(s) de datos de cliente 1150 que puede ser empleado para almacenar información local para el cliente(s) 1110. Similarmente, el servidor(es) 1 120 está operativamente conectado a uno o más almacenamiento(s) de dato del servidor 1 130 que puede ser empleado para almacenar información local para los servidores 1 140. Con referencia a la Figura 12, un ambiente ilustrativo 1200 para implementar varios aspectos de la invención incluye una computadora 1212. La computadora 1212 incluye una unidad de procesamiento 1214, una memoria de sistema 1216, y un conductor común de sistema 1218. El conductor común de sistema 1218 acopla componentes de sistema incluyendo, pero no limitándose a, la memoria de sistema 1216 a la unidad de procesamiento 1214. La unidad de procesamiento 1214 puede ser cualquiera de varios procesadores disponibles. Los microprocesadores dobles y otras arquitecturas de multiprocesador también pueden ser empleados como la unidad de procesamiento 1214. El conductor común de sistema 1218 puede ser cualquiera de diferentes tipos de estructura(s) de conductor común incluyendo el conductor común de memoria o controlador de memoria, un conductor común periférico o conductor común externo y/o un conductor común local que utiliza cualquiera de una variedad de arquitecturas de conductor común disponible incluyendo, pero no limitándose a, Arquitectura de Estándar de Industria (ISA), Arquitectura de Microcanai (MSA), ISA Extendido (EISA), Electrónicos de Conducción Inteligente (IDE), Conductor Común Local de VESA (VLB), Interconexión de Componente Periférico (PCI), Conductor Común de Tarjeta, Conductor Común en Serie Universal (USB), Puerto de Gráfico Avanzado (AGP), Conductor Común de Asociación Internacional de Tarjeta de Memoria de Computadora Personal (PCMCIA), Muro Contra Incendios (I EEE 1394) , e Interfase de Sistema de Computadora Pequeña (SCSI). La memoria de sistema 1216 incluye memoria volátil 1220 y memoria no volátil 1222. El sistema de entrada/salida básico (BIOS), que contiene las rutinas básicas para transferir información entre elementos dentro de la computadora 1212, tal como durante el arranque, está almacenado en memoria no volátil 1222. A manera de ilustración, y no de limitación, la memoria no volátil 1-222 puede incluir memoria solo de lectura (ROM), ROM programable (PROM) , ROM eléctricamente programable (EPROM), ROM eléctricamente borrable (EEPROM), o memoria instantánea. La memoria volátil 1220 incluye memoria de acceso aleatorio (RAM), que actúa como una memoria caché externa. A manera de ilustración y no de limitación, ia RAM está disponible en muchas formas tal como RAM sincrónica (SRAM), RAM dinámica (DRAM), DRAM sincrónica (SDRAM), SDRAM de clasificación de datos dobles (DDR SDRAM), SDRAM mejorada (ESDRAM), DRAM con enlace de sintonización (SLDRAM), y RAM de conductor común de RAM directa (DRAAM). La computadora 1212 también incluye medios de almacenamiento de computadora removibles/no removibles, volátiles/no volátiles. Por ejemplo, la Figura 12 ilustra un almacenamiento de disco 1224. El almacenamiento de disco 1224 incluye, pero no está limitado a, dispositivos como una unidad de disco magnético, unidad de disco flexible, unidad de cinta, unidad de Jaz, unidad de Zip, unidad de LS-100, tarjeta de memoria instantánea, o cartucho de memoria. Además, el almacenamiento de disco 1224 puede incluir medios de almacenamiento de forma separada o en combinación con otros medios de almacenamiento incluyendo, pero no limitándose a, una unidad de disco óptico tal como un dispositivo de ROM de disco compacto (CD-ROM) , unidad regrabable de CD (Unidad de CD-R), unidad reescribible de CD (Unidad de CD-RW) o una unidad de ROM de disco versátil digital (DVD-ROM). Para facilitar la conexión de los dispositivos de almacenamiento de disco 1224 al conductor común de sistema 1228, se utiliza típicamente una interfase removible o no removible tal como la interfase 1226. Se debe apreciar que la Figura 12 describe el software que actúa como un intermediario entre usuarios y los recursos de computadora básicos descritos en el ambiente operativo adecuado 1200. Tal software incluye un sistema operativo 1228. El sistema operativo 1228, que puede estar almacenado en el almacenamiento de disco 1224, actúa para controlar y distribuir recursos del sistema de computadora 1212. Las aplicaciones del sistema 1230 toman ventaja del manejo de recursos por el sistema operativo 1228 a través de los módulos de programa 1232 y datos de programa 1234 almacenados ya sea en la memoria de sistema 1216 o en el almacenamiento de disco 1224. Se debe apreciar que la invención sujeta puede ser implementada con varios sistemas operativos o combinaciones de sistemas operativos. Un usuario ingresa comandos e información en la computadora 1212 a través del dispositivo(s) de entrada 1236. Los dispositivos de entrada 1236 incluyen, pero no se limitan a, un dispositivo de señalamiento tal como un ratón, seguibola, aguja, almohadilla sensible al tacto, teclado, micrófono, palanca de mandos, almohadilla de juegos, antena parabólica, escáner, tarjeta de sintonizador de TV, cámara digital, cámara de vídeo digital, cámara web, y similares. Estos y otros dispositivos se conectan a la unidad de procesamiento 1214 a través del conductor común de sistema 1218 a través del puerto(s) de interfase 1238. Ei puerto(s) de interfase 1238 incluye, por ejemplo, un puerto en serie, un puerto paralelo, un puerto de juego y un conductor común en serie universal (USB). El dispositivo(s) de salida 1240 utiliza algunos del mismo de tipos de puertos como el dispositivo(s) de entrada 1236. De esa forma, por ejemplo, se puede utilizar un puerto de USB para proporcionar entrada a la computadora 1212, y dar salida a la información de la computadora 1212 a un dispositivo de salida 1240. El adaptador de salida 1242 es proporcionado para ilustrar que existen algunos otros dispositivos de salida 1240 como monitores, bocinas, impresora, entre otros dispositivos de salida 1240, que requieren adaptadores especiales. Los adaptadores de salida 1242 incluyen, a manera de ilustración y no de limitación, tarjetas de vídeo y sonido que proporcionan un medio de conexión entre el dispositivo de salida 1240 y el conductor común de sistema 1218. Se debe notar que otros dispositivos y/o sistemas de dispositivo proporcionan tanto capacidades de entrada como de salida tal como computadora(s) remota 1244. La computadora 1212 puede operar en un ambiente en red que utiliza conexiones lógicas a una o más computadoras remotas, tal como computadora(s) remota 1244. La computadora(s) remota 1244 puede ser una computadora personal, un servidor, un enrutador, una PC de red, una estación de trabajo, una aplicación a base de microprocesador, un dispositivo par u otro nodo de red común y similares, y típicamente incluye muchos o todos los elementos descritos relativos a la computadora 1212. Para propósitos de brevedad, solo se ilustra un dispositivo de almacenamiento de memoria 1246 con la computadora(s) remota 1244. La computadora(s) remota 1244 está lógicamente conectada a la computadora 1212 a través de una ¡nterfase de red 1248 y después físicamente conectada a través de la conexión de comunicación 1250. La interfase de red 1248 abarca redes de comunicación alámbrica y/o inalámbrica tal como redes de área local (LAN) y redes de área amplia (WAN). Las tecnologías de LAN incluyen Interfase de Datos Distribuida de Fibra (FDD I), Interfase de Datos Distribuida de Cobre (C DDl), Ethernet, Anillo de señal y similares. Las tecnologías de WAN incluyen, pero no se limitan a, enceles de punto a punto, redes de conexión de circuito como Redes Digitales de Servicios I ntegrados (ISDN) y variaciones de las mismas, redes de cambio de paq uete, y Líneas de Suscriptor Digital (DS L) . La conexión(es) de comunicación 1250 se refiere al hardware/software empleado para conectar la interfase de red 1248 al conductor común 1218. Mientras la conexión de comunicación 1250 es mostrada para claridad ilustrativa dentro de la computadora 1212, puede también ser externa a la computadora 1212. El hardware/software necesario para la conexión a la interfase de red 1248 incluye, solo para propósitos ilustrativos, tecnolog ías internas y externas tal como, módem que incluye módems de grados de teléfono regular, módems de cable y módems de DSL, adaptadores de ISDN , y tarjetas de Ethernet. Lo que se ha descrito anteriormente incluye ejemplos de. los componentes y métodos. Por supuesto, no es posible describir todas las combinaciones concebibles de componentes o metodologías, pero un experto ordinario en la técnica reconocerá que muchos otras combinación y cambios de la invención sujetas son posibles. Por consiguiente, los ejemplos pretenden abarcar todas tales alteraciones, modificaciones, y variaciones que caen dentro del espíritu y alcance de las reivindicaciones anexas. En particular y con respecto a las varias funciones realizadas por los componentes antes descritos, dispositivos, circuitos, sistemas y similares, los términos (incluyendo una referencia a un "medio") utilizados para describir tales componentes pretenden corresponder, a menos que se indique de otra forma, a cualquier componente que realiza la función específica del componente descrito (por ejemplo, un equivalente funcional), incluso aunque no sea estructuralmente equivalente a la estructura descrita, que realiza la función en los ejemplos aquí ilustrados. Con respecto a esto, también se reconocerá que un sistema así como un medio legible por computadora que tiene instrucciones ejecutables por computadora que comprende componentes o para realizar los actos y/o eventos de varios métodos aquí mencionados y descritos. Además, mientras una característica particular de la invención puedo haber sido descrita con respecto solo a una de diferentes implementaciones, tal característica puede estar combinada con una o más otras características de las otras implementaciones mientras puede ser deseado y ventajoso para cualquier aplicación dada o particular. Además, hasta donde los términos "incluye", y "que incluye" y las variantes de los mismos son utilizados ya sea en la descripción detallada o las reivindicaciones, estos términos pretenden ser inclusivos en una forma similar al término "que comprende".

Claims

REIVINDICACIONES 1.- Un sistema para automatizar procesamiento de datos, que comprende: un módulo de programación de usuario final que está integrado con un sistema de archivo importante y que delinea un evento de un sistema de cómputo a al menos una acción automática que es recibida por un usuario final; y un controlador de evento que responde al evento y causa que al menos una acción sea realizada en respuesta a una ocurrencia del evento. 2.- El sistema de acuerdo con la reivindicación 1 , en donde el evento es creado por un sistema operativo. 3.- El sistema de acuerdo con la reivindicación 1 , en donde el evento es creado por una aplicación de monitor. 4.- El sistema de acuerdo con la reivindicación 1 , en donde el evento es creado por una aplicación de usuario. 5.- El sistema de acuerdo con la reivindicación 4, en donde la acción automática es realizada por una segunda aplicación de usuario que es diferente de la aplicación de usuario que creó el evento. 6.- El sistema de acuerdo con la reivindicación 4, que además comprende un sistema de archivo que está integrado con el módulo de programación de usuario final que proporciona acceso a datos almacenados. 7.- El sistema de acuerdo con la reivindicación 6, en donde el sistema de archivo es un sistema de archivo distribuido . 8.- El sistema de acuerdo con la reivindicación 7, en donde el sistema de archivo distribuido es distribuido a través de una pluralidad en red de dispositivos de almacenamiento cooperativos . 9. - Un método para automáticamente procesar datos, que comprende: identificar un evento de impulso en un sistema de cómputo que puede ser utilizado para iniciar una acción definida por usuario en datos en un sistema de archivo integrado; especificar una acción definida por usuario final para que se tome una detección del evento identificado; y realizar automáticamente la acción definida par usuario final al detectar la ocurrencia del evento identificado . 1 0.- El método de acuerdo con la reivindicación 9, en donde el evento de impulso es un evento que es creado por al menos uno de un sistema operativo, una aplicación de monitor, y una apl icación de usuario. 1 1 .- El método de acuerdo con la reivindicación 9, en donde el realizar automáticamente la acción definida por usuario final se realiza por al menos un sistema operativo, una aplicación de monitor, y una aplicación de usuario . 12.- El método de acuerdo con la reivindicación 9, que además comprende: acceder a un almacenamiento de datos para obtener instrucciones de procesamiento para la acción definida por usuario final . 13.- El método de acuerdo con la reivindicación 12, en donde el acceder a un almacenamiento de datos incluye acceder a un sistema de archivo integrado. 14.- El método de acuerdo con la reivindicación 13, en donde el acceder al sistema de archivo integrado incluye acceder a un sistema de archivo distribuido. 15.- Un sistema para procesar automáticamente datos, que comprende: medios para identificar un evento de impulso en un sistema de cómputo que puede ser utilizado para iniciar un acción definida por usuario en datos en un sistema de archivo integrado; medios para especificar una acción definida por usuario final para ser tomada después de la detección del evento identificado; y medios para realizar automáticamente la acción definida por usuario final al detectar la ocurrencia del evento identificado. 16.- El sistema de acuerdo con la reivindicación 15, en donde el evento de impulso es un evento que es creado por al menos un sistema operativo, una aplicación de monitor, y una aplicación de usuario. 17.- El sistema de acuerdo con la reivindicación 15, en donde los medios para realizar automáticamente la acción definida por usuario final incluyen al menos uno de un sistema operativo, una aplicación de monitor, y una aplicación de usuario. 18.- El sistema de acuerdo con la reivindicación 15, que además comprende: medios para acceder a un almacenamiento de datos para obtener instrucciones de procesamiento para la acción definida por usuario final. 19.- El sistema de acuerdo con la reivindicación 15, en donde los medios para acceder al almacenamiento de datos incluyen medios para acceder a un sistema de archivo integrado. 20.- El sistema de acuerdo con la reivindicación 19, en donde los medios para acceder a un sistema de archivo integrado incluyen medios para conectarse a un sistema de archivo remoto.