MXPA04012867A - Facturacion de umbral. - Google Patents

Abstract

La presente invencion involucra un sistema y un metodo que facilitan una experiencia de compra, en parte consolidado cualquier numero de compras y sus respectivas cantidades de cargo hasta que las compras o cantidades de cargo alcanzan un nivel de umbral. El nivel de umbral puede basarse en parte en los recursos utilizados (consumidos o comprados) o en el valor monetario correspondiente. El nivel de umbral puede ser determinado basandose por lo menos ne parte en varios factores tales como el tipo de recurso que se esta comprando, el volumen de recursos comprados en un momento o durante un periodo de tiempo, historia de pagos del cliente, historia de uso del cliente, realimentacion recibida del proveedor de pagos del cliente, el tipo de vehiculo de pago (por ejemplo, tarjeta de credito, tarjeta de valor almacenado), momento de la compra, etc. Cuando el umbral es alcanzado, el pago es solicitado asincronicamente. La cuenta del cliente puede ser suspendida o cancelada si el pago no puede ser asegurado dentro de una cantidad de tiempo deseada.

Description

FACTURACIÓN DE UMBRAL CAMPO TÉCNICO Esta Invención se refiere a sistemas y métodos que facilitan la compra en línea y en particular, ésta se refiere a facturar a clientes basándose en parte en un valor de umbral dinámicamente determinado.

ANTECEDENTES DE LA INVENCIÓN La venida de redes de comunicaciones globales tal como el Internet, ha presentado oportunidades comerciales para alcanzar considerables números de clientes potenciales. En particular, la compra y el ir de compras en línea esta subiendo, ya que se demuestra por el incremento de las ventas al por menor en línea. Desde música, tarjetas de felicitación hasta comestibles, más y más consumidores están comprando a minoristas en Internet por una variedad de razones tales como conveniencia, selección y estímulos en precio ofrecidos únicamente en línea. Sin embargo, la experiencia de Ir de compras en línea no esta sin sus obstáculos y problemas. Por ejemplo, el proceso de compra puede ser largo y arduo, particularmente cuando únicamente se quiere comprar un pequeño número de artículos por una cantidad en dólares relativamente baja. Esto es comúnmente referido como compra por artículo, lo cual es el método convencional que se emplea hoy en día. Un ejemplo de esto es comprar una tarjeta de felicitación en línea, la cual es normalmente y relativamente barata (por ejemplo $2.00). El bajo costo del artículo comparado con el proceso de compra que requiere mucho tiempo puede resultar en un freno para clientes actuales y/o de retorno. Como una alternativa para es esquema de facturación por artículo, algunos minoristas en línea han implementado la facturación por periodo de tiempo, por medio de la cual los clientes se facturan una vez al mes o una vez al día, por ejemplo. Sin embargo, este tipo de facturación presenta otra serie de problemas. Por ejemplo, facturar únicamente a un cliente una vez al día o al mes puede permitir al cliente comprar o descargar varios productos tal como canciones, antes de que se descubra que el cliente no puede pagar por las mercancías "compradas". Por eso, los riesgos de no pago y/o deuda incrementan significativamente para el minorista. Además, hay una necesidad impropia de mejorar la compra en línea desde las perspectivas de ambos, los clientes y el minorista.

BREVE DESCRIPCIÓN DE LA INVENCIÓN La siguiente presenta una descripción simplificada de la invención para suministrar un entendimiento básico de algunos aspectos de la invención. Esta descripción no es un panorama general extenso de la invención. No tiene la intención de identificar los factores críticos/claves de la invención o delimitar el ámbito de ia invención. Su único propósito es presentar algunos conceptos de la invención en una forma simplificada como un preludio para la descripción mas detallada que se presenta después. La presente invención se suministra para sistemas y métodos que permiten a un cliente comprar una pluralidad de mercancías y/o servicios (por ejemplo, descargar mercancías, hacer uso de servicios de cuota en línea, etc.) durante un periodo de tiempo sin ser impedido por un proceso de cargo por cada transacción por separado. Más específicamente, la invención sujeto implica emplear un nivel de recursos de umbral basándose en al menos en parte en cualquier número de parámetros, los cuales corresponde a los clientes o usuarios respectivos. Los cargos por usuario esencialmente se consolidan y almacenan en una fila (por ejemplo, local o no local) o memoria intermedia sin restricción hasta que una cantidad de facturación de umbral se alcanza, en el punto en el cual el instrumento de pago del cliente se carga en su cuenta o se cobra. Además, la presente invención soporta cargar asincrónicamente a un vehículo de pago especificado de la memoria intermedia sin restricción cuando un valor o nivel de umbral particular se alcanza. El valor de umbral se puede determinar en parte por cualquier combinación de preferencias del usuario y/o preferencias de sistema del minorista así como el tipo de mercancía o servicio, la cantidad de unidades, datos históricos, instrumento de pago y/o periodo de "compra" o descarga así como una miríada de otros factores. En un ejemplo, los usuarios de venta al por menor pueden estar más dispuestos a incrementar su cantidad de riesgo durante temporadas de compra altas tales como Noviembre y Diciembre pero elegir establecer límites más moderados en otras épocas del año. En otro ejemplo, la época del año en combinación con una compra del cliente particular e historia de pagos puede resultar en un valor de umbral mas alto comparado con otro cliente con una historia de pagos menos favorable. Según un aspecto de la invención, los valores de umbral pueden fluctuar dinámicamente como una función del usuario de venta al por menor particular. Además para evaluar el mérito de crédito e historias de pagos del cliente, otros factores tales como tipo de pago, tipo de mercancía/servicio, cantidad de mercancías, etc. , puede influir en el valor de umbral cuando se determina por usuario así como la duración de aquel umbral particular. Por ejemplo, el valor de umbral puede tener una escala de plazo real, al final de la cual, el valor de umbral se examina de nuevo y se ajusta, si es necesario, o deseado, basándose en una reevaluación de los parámetros pertinentes. En otro aspecto, el cliente puede ser capaz de delimitar además, valores de sub-umbral basándose en un tipo de mercancía, por ejemplo. Por ejemplo, imagina que un comerciante vende varios productos tales como artículos de comida, ropa, electrónicos, libros, y música. Además, un valor de umbral de $1 00 se establece por el comerciante para un cliente particular, en donde al cliente se le factura tan pronto como un valor de $100 de compras se hace y compras adicionales no se puede hacer hasta que un pago de $100 se hace. Dado que el valor de umbral se establece hasta $100, el cliente puede además delimitar la asignación del valor de umbral entre los tipos de productos ofrecidos para venta por el comerciante. Por ejemplo, un umbral de $30 se puede establecer para cualquier de los artículos no comestibles- significa que $30 del umbral de $100 se puede gastar en artículos no comestibles. De forma alternativa, los sub-umbrales se pueden basar en porcentaje, lo cual puede ser útil ya que los valores de umbral pueden varia. Por ejemplo, el cliente puede definir que el 30% de cualquier valor de umbral se puede gastar en artículos no comestibles o más específicamente, en música. Se comprende que el valor de umbral puede referirse a un valor monetario o un valor de recurso, por medio del cual el valor de recurso corresponde a cualquier unidad de consumo de mercancía, objeto descargable o uso que se puede o no se puede valorar. Además, artículos adquiribles (por ejemplo, uso de recurso) se pueden modelar como ofertas o acontecimientos, el costo de los cuales se puede basar en el valor de cada recurso utilizado. El uso de recurso se puede registrar por un componente y algún tiempo después, el uso de recurso se puede convertir en un valor monetario. Por lo tanto, en un aspecto, los acontecimientos se puede valorar o pre-valorar de manera que se asocien con un valor monetario en el momento de "compra" por el cliente. De forma alternativa, el valor monetario que se asocia con cada acontecimiento de "compra" se puede asignar o atribuir al uso de recurso o compra en el momento de facturación (por ejemplo, cargo a tarjeta de crédito o pago solicitado del proveedor de pagos). Cuando un valor de umbral se alcanza, el instrumento de pago designado del cliente se puede cargar a la cuenta o pagar. Sin embargo, cuando el pago se puede hacer por el cliente o el proveedor de pagos del cliente, varias acciones se pueden tomar. Por ejemplo, intentos de compra futura se pueden negar tal como hasta que el pago solicitado se hace. Además, el valor de umbral se puede disminuir cuando las capacidades de compra se reanudan, si más de un intento se requirió para obtener el pago. Mensajes de aviso también se pueden enviar periódicamente al cliente particular notificándole del estado de su cuenta así como posibles consecuencias que resulten del no pago o pagos retrasados. Según aún otro aspecto de la invención, puede ser necesario notificar al usuario cuando se estén acercando su solicitud de pago y umbral antes de que el umbral se alcance para evitar la suspensión del servicio. Esto puede ser aplicable, dependiendo del instrumento de pago particular empleado para liquidar la cuenta del cliente (por ejemplo, cargo directo a la cuenta en algunos países; pago obligatorio en Japón). Como resultado, otros umbrales ( además de la cantidad de cargo de umbral) se pueden utilizar como un umbral de notificación y un umbral de suspensión. El umbral de notificación puede corresponder a una cantidad (por ejemplo, en términos de moneda, puntos, y/o unidades) que es menor que la cantidad de facturación de umbral, por medio del cual, el usuario puede recibir un aviso para liquidar su cuenta antes de que la cantidad de facturación de umbral se alcance o exceda. De forma similar, el umbral de suspensión puede corresponder a una cantidad (en términos de moneda, puntos y/o unidades) que es mayor que el umbral de notificación y/o el umbral de facturación, por medio del cual, la cuenta del usuario se puede suspender tan pronto como la cantidad de suspensión se alcanza. Para el cumplimiento de lo anteriormente mencionado y partes relacionadas, ciertos aspectos ilustrativos de la invención se describen en la presente con respecto a la siguiente descripción y los dibujos anexos. Estos aspectos son indicativos, sin embargo, de unos cuantos de los varios modos en los cuales los principios de la invención se pueden emplear y la presente invención tiene la intención de incluir todos tales aspectos y sus equivalentes. Otras ventajas y características originales de la invención se pueden volver evidentes de la siguiente descripción detallada de la invención cuando se considera en conjunto con los dibujos.

BREVE DESCRIPCIÓN DE LOS DIBUJOS La Fig. 1 es un diagrama de bloques de nivel alto de un sistema que facilita la consolidación de compra y facturación de umbral de acuerdo con un aspecto de la presente invención. La Fig. 2 es un diagrama de bloques esquemático de un sistema que registra el uso de recurso de cliente y solicita el pago por uso de recurso cuando una cantidad de umbral se alcanza, de acuerdo con un aspecto de la presente invención. La Fig. 3 es un diagrama esquemático de factores típicos que puede influir en un valor de umbral de acuerdo con un aspecto de la presente invención. La Fig. 4 es un diagrama de flujo de un proceso típico que facilita la consolidación de compra y la facturación de umbral de acuerdo con un aspecto de la presente invención. La Fig. 5 es un diagrama de flujo de un proceso típico que facilita la consolidación de compra y la facturación de umbral de acuerdo con un aspecto de la presente invención. La Fig. 6 es un diagrama de flujo de un proceso típico que continua del proceso de la Fig. 5 de acuerdo con un aspecto de la presente invención. La Fig. 7 es un diagrama de flujo de un proceso típico que continua de un aspecto del proceso de la Fig. 6 de acuerdo con un aspecto de la presente invención. La Fig. 8 es un diagrama de flujo típico que facilita la facturación de umbral de acuerdo con un aspecto de la presente invención. La Fig. 9 es un ambiente típico para implementar varios aspectos de la invención.

DESCRIPCIÓN DETALLADA DE LA INVENCIÓN La presente invención ahora se describe con referencia a los dibujos, en donde números de referencia similares se usan para referirse a elementos similares desde el principio hasta el final. En la siguiente descripción, con el objeto de explicación, numerosos detalles específicos se enuncian para suministrar un entendimiento completo de la presente invención. Puede ser evidente, sin embargo, que la presente invención se puede practicar sin estos detalles específicos. En otros casos, mecanismos y estructuras bien conocidas se muestran en forma de diagrama de bloques para facilitar la descripción de la presente invención. Como se usa en esta solicitud, el término "componente" y "sistema" tiene la intención de referirse a una entidad relacionada con una computadora, ya sea hardware, una combinación de hardware y software, software, o software en ejecución. Por ejemplo, un componente puede ser, pero no se limita a ser, un corredor de proceso en un procesador en un procesador, un procesador, un objeto, un ejecutable, una línea de ejecución, un programa, y/o una computadora. Para ilustración, ambos, un corredor de aplicación en un servidor y el servidor pueden ser un componente. Uno o más componentes puede radicar dentro de un proceso y/o línea de ejecución y un componente se puede ubicar en una computadora y/o distribuir entre dos o más computadoras. La invención sujeto puede incorporar varias técnicas y/o esquemas de inferencia con respecto a determinar automáticamente un valor de umbral tal como por cliente (por ejemplo, usuario). Como se usa en la presente, el término "inferencia" se refiere generalmente al proceso de discutir o inferir a cerca de las condiciones del sistema, ambiente, y/o usuario de una serie de observaciones cuando se capturan vía acontecimientos y/o datos. La inferencia se puede emplear para identificar un contexto o acción específica, o puede generar una distribución de probabilidad sobre las condiciones, por ejemplo. La inferencia puede ser probabilística - esto es, la computación de una distribución de probabilidad sobre las condiciones de interés basándose en una consideración de datos y acontecimientos. La inferencia también se puede referir a técnicas que se emplean para componer acontecimientos de nivel más alto de una serie de acontecimientos y/o datos. Tal inferencia resulta en la construcción de nuevos acontecimientos o acciones de una serie de acontecimientos observados y/o datos de acontecimiento almacenados, sí o no los acontecimientos se correlacionen en proximidad temporal cercana, y si los acontecimientos y datos vienen de uno o varias fuentes de datos y acontecimientos. Se comprende que la presente invención se puede utilizar e implementar por cualquier tipo de entidad vendedora, minorista, comerciante, proveedor de servicio en línea. También se debe comprender que el término "cliente" cuando se emplea en la invención del momento puede referirse a cualquier persona o entidad que desea comprar y/o descargar cualquier artículo(s) sometido a un cargo o cuota por tal compra o descarga. La presente invención se suministra para un sistema y método que permite a un proveedor de servicio o comerciante en línea hacer un cargo (por ejemplo, cargar en cuenta o facturar) a un instrumento de pago del cliente (por ejemplo, cuenta de banco, tarjeta de crédito, tarjeta de débito, saldo acreedor en la cuenta del usuario por el comerciante) cuando el cliente ha comprado un valor establecido de mercancías. El valor establecido de las mercancías corresponde a un valor de recurso de umbral. Por ejemplo, un valor establecido de mercancías, o valor de umbral, puede ser $10 de productos o servicios. Por eso, cuando el cliente ha comprado al menos $10 del producto o servicio en ya sea un acontecimiento (por ejemplo, transacción) o sobre un número de acontecimientos (por ejemplo, cuando se acumulan los acontecimientos), el vehículo de pago designado se carga para liquidar la cuenta con el comerciante. De forma alternativa, el valor de recurso también puede corresponder a una unidad consumible tal como minutos, puntos, unidades, y lo similar. Además, los acontecimientos se pueden almacenar y/o rastrear durante cualquier periodo de tiempo hasta que un valor de recurso de umbral correspondiente se alcanza, tiempo en el cual el pago se requiere y solicita para tales acontecimientos. Este escenario se ilustra de forma esquemática en la Fig. 1 . La Fig. 1 muestra un diagrama de bloques de nivel alto de un sistema de facturación de umbral 100 de acuerdo con un aspecto de la presente invención. En particular, una entidad de compra 1 10 (por ejemplo, cliente, comprador, etc.) tiene contacto y/o se comunica con un proveedor de servicio o vendedor en línea 120. Las comunicaciones que se reciben de la entidad de compra 1 10 por el vendedor en línea 120 entonces, se pueden analizar por una identificación de acontecimiento y componente de rastreo 130 para determinar si la comunicación de la entidad de compra 1 10 constituye un acontecimiento- el acontecimiento que se refiere a una compra o descarga de algún recurso(s) (por ejemplo, mercancías o servicios). Asumiendo que un primer acontecimiento no alcanza el valor de recurso de umbral, acontecimientos posteriores (por ejemplo, segundo acontecimiento, tercer acontecimiento, etc.) además el primer acontecimiento se puede rastrear y totalizar por la identificación de acontecimiento y el componente de rastreo 130. Tan pronto como los acontecimientos alcanzan (o exceden) el valor de recurso de umbral, un componente de cargo a cuenta 140 se puede avisar para hacer un cargo al instrumento de pago de la entidad de compra. Ejemplos de un instrumento de pago incluyen una tarjeta de crédito, una cuenta de banco (débito), y tarjeta de débito. De forma alternativa, un saldo acreedor (por ejemplo, crédito de valor almacenado con el comerciante) se puede mantener con el vendedor en línea particular 120 de manera que la cantidad facturada se puede restar del saldo acreedor. Se comprende que el pago es solicita por al menos el valor de recurso de umbral si éste corresponde a un valor monetario o una unidad de consumo. Por ejemplo, si el valor de recurso de umbral se refiere a un valor monetario (por ejemplo, $20), al menos que la cantidad se facture al cliente para pago inmediato. Sin embargo, cuando el valor de recuso de umbral se alcanza y excede (por ejemplo, ultimo acontecimiento que llevó al valor de recurso de umbral arriba de $15 hasta $35 y el umbral es de $20), el saldo completo (por ejemplo, $35) se puede facturar al cliente para llevar la deuda del saldo a $0. De forma alternativa, únicamente el pago inmediato de una cantidad correspondiente al valor de umbral se puede requerir a juicio del vendedor. Cuando el pago solicitado se recibe por el vendedor 120, acontecimientos (compra) se pueden reanudar entre la entidad de compra 1 1 0 y el vendedor 120. En referencia ahora a la Fig. 2, se ilustra un sistema de cargo a cuenta en línea 200 de acuerdo con un aspecto de la presente invención. El sistema implica la interacción con uno o más clientes 210, por medio del cual una entrada se puede recibir de los uno o más clientes en la forma de acontecimiento(s), por ejemplo. Un acontecimiento se puede referir a una transacción de compra o un intento de hacer una compra (por ejemplo, que incluye descargas) por un cliente o entidad que se puede o no se puede someter a facturación de umbral (por ejemplo, pago inmediato de alguna cantidad tal como al menos el valor de umbral). Un componente de detección de acontecimiento 220 recibe una entrada del cliente 210 y detecta si la entrada constituye un acontecimiento que se somete al esquema de facturación de umbral. Un acontecimiento puede comprender objetos que se van a comprar (por ejemplo, uso de recurso), por ejemplo. Si la entrada se identifica o reconoce como un acontecimiento, un registrador de uso de recurso 230 puede registrar tal uso de los recursos respectivos. Por ejemplo, si los recursos se asignan a un valor monetario, entonces el valor correspondiente de recursos se puede registrar como se "usa" con respecto a un valor de recurso de umbral. Esto es, si el valor de los recursos utilizados después de 2 acontecimientos se ha registrado es $5 y el valor de recurso de umbral es $25, entonces el cliente tiene un valor de $20 de recursos para comprar antes de que el pago de al menos 25$ se requiera por el comerciante en línea. Esto significa que acontecimientos adicionales se pueden iniciar por el cliente antes de que el umbral se alcance. Como los eventos se acumulan , se pueden almacenar en una fila no local 240 (por ejemplo, memoria intermedia sin restricción) para además mejorar la seguridad y clasificación del sistema. De forma alternativa, si los recursos relacionados a una unidad de consumo tal como tiempo o puntos, entonces los recursos utilizados hasta aq uí, se pueden registrar y acumular hasta que el valor de recurso de umbral se alcanza. Por ejemplo, imagina q ue los recursos utilizados se refieren a un número de horas y el valor de recurso de umbral es de 50 horas; y cuando se alcanza, al cliente se le hace un cargo de $25.00. Por consiguiente, si un primer y segundo acontecimiento alcanza 1 2 horas en total (por ejemplo 4 horas y 8 horas, respectivamente), el cliente puede aún "comprar" o hacer uso de 38 horas (por ejemplo, recurso) antes de que se carguen $25. Un analizador-procesador de recurso 250 puede determinar si el valor de recurso de umbral se ha alcanzado y/o excedido, analizando (por ejemplo, totalizar) el contenido de la memoria intermedia sin restricción 240. Si el umbral no se ha cumplido, entonces el componente de detección de acontecimiento 220 puede continuar para detectar y/o identificar acontecimientos posteriores que se llevan a cabo por el cliente 21 0. Sin embargo, si el umbral se ha cumplido, un componente de solicitud de cargo a cuenta 260 se puede avisar para hacerle un cargo de forma asincrónica al cliente al menos de una parte de la cantidad total de las compras de la memoria intermedia sin restricción 240. En este o casi en este momento, la cuenta del cliente (por ejemplo, recurso o cuenta de usuario) se puede reiniciar o reajustar para algún valor para indicar que el pago se está solicitando por al menos una parte de los recursos utilizados (por ejemplo, objetos descargados o comprados). En algunos casos, este valor puede ser cero, lo cual ocurre cuando el pago inmediato por el uso de recurso total se solicita. Sin embargo, en otros casos, el valor puede ser negativo tal como si un primer uso de recurso es gratis (por ejemplo, los primeros 10 minutos son gratis o los primeros $5 de compra son gratis). De forma opcional, el valor puede ser un número no cero, positivo, el cual puede indicar que el pago se solicitó por únicamente una parte de la cuenta total, por medio del cual la parte restante cae bajo el valor de umbral actual. En este caso, un saldo aún se puede deber al comerciante en línea y se puede cobrar la próxima vez que el valor de umbral se alcance. Por ejemplo, imagina que el valor de recurso de umbral es 50$. Cuando el cliente gasta $50 totales a través de una o más compras, a su proveedor de pagos se le hace un cargo de $50. Por lo tanto, su cuenta se puede reducir a $0 si un pago de $50 se carga al instrumento de pago. De forma alternativa, su cuenta se puede reducir a $5.00 para indicar que los primeros $5 del recurso son gratis. Finalmente, su cuenta se puede reducir a cualquier cantidad debajo de los $50 tal como $25, lo cual significa que un pago de $25 se cargó para llevar al cliente por debajo de la cantidad de umbral de $50. Por consiguiente, al cliente se le puede permitir continuar comprando hasta que el umbral de $50 se alcance otra vez. De forma opcional, si las compras del cliente sumarizan $65 (por ejemplo, compra total incrementada de $45 a 65$) y el valor de umbral es $50, al menos un pago de $50 se puede solicitar (por ejemplo, cantidad solicitada para pago corresponde al valor de umbral); por eso, se dejan $15 en la cuenta (base de datos) hasta que el valor de umbral se alcance otra vez. Cuando el componente de solicitud de cargo a cuenta se avisa, una solicitud de cargo asincrónico se puede poner en fila para un sistema de instalación de procesamiento de mensaje ( PF) 270, el cual puede controlar la ejecución de acciones relativamente arbitrarias tales como solicitudes de cargo, por ejemplo. El sistema MPF 270 puede ser similar a una fila de mensaje. Dentro del sistema MPF 270, tal como en una línea diferente y/o en una máquina diferente, un componente del sistema MPF recoge una acción de cargo pendiente, localiza el código de cargo apropiado para ejecutar (por ejemplo, a través de vínculo dinámico) y luego visitas que codifican. El código de cargo asincrónico puede entonces leer el registro de cargo (por ejemplo, cargo total o cantidad que se va a cargar en el periodo actual) de la memoria intermedia sin restricción 240 e intento de liquidación contra el proveedor de pagos (por ejemplo, tarjeta de crédito, cuanta de banco, crédito de valor almacenado, etc.) por la cantidad especificada o por alguna parte de la cantidad total, dependiendo de las preferencias del comerciante. Si el cargo tiene éxito, entonces se puede registrar como exitoso en la memoria intermedia 240 (o base de datos). Después, un mensaje se puede enviar al cliente para notificarle que se hizo un cargo en su instrumento de pago y/o que se hizo el pago. Sin embargo, si el cargo falla o se rechaza, entonces se puede registrar como una negativa en la memoria intermedia 240; y un re-intento para obtener el pago se puede programar para algún periodo en el futuro y señalar en la memoria intermedia 240 también. Como una consecuencia adicional del pago fallido, la cuenta del cliente se puede suspender al menos temporalmente para detener otras compras o descargas que se van a hacer por el cliente. En particular, el comerciante o proveedor de servicio de suscripción puede recibir la notificación del pago fallido por otra acción de MPF asincrónica, la cual esencialmente informa al proveedor de servicio impedir el servicio al cliente. Intentos de cargo posteriores se pueden llevar a cabo por un proceso de pago de partida diaria. Si el cargo finalmente tiene éxito, entonces las capacidades de compra o suscripción del cliente se puede reanudar (por ejemplo, reinstalar). De otro modo, las notificaciones de negativas repetidas se pueden enviar al cliente. Después de un periodo de no . pago, la cuenta o servicio de suscripción del cliente finalmente se puede cancelar. Además, la presente invención mitiga perdidas y riesgos de deuda morosa para proveedores de servicio y/o comerciantes en línea, requiriendo la liq uidación o pago inmediato de la cuenta del usuario cuando un valor de umbral se alcanza. Además, cuotas de transacción de tarjeta de crédito o banco y/o costos generales se pueden minimizar ya que las compras se consolidan (por ejemplo, compras consolidadas resultan en menos transacciones de tarjeta de crédito y por eso, menos cuotas de tarjeta de crédito). De forma similar, compras de artículos de línea en un informe de tarjeta de crédito, por ejemplo, se pueden reducir para consolidar las transacciones. Finalmente, el cargo puede ocurrir en seguida, sin incrementar el estado latente de visita para proveedores de servicio y comerciantes en línea, los cuales reportan las compras, las cuales se pueden contribuir para la mitigación de riesgos de deuda morosa o perdidas mercantiles. Como se describe arriba, el sistema 200, por el código de cargo asincrónico, intenta la liquidación in mediata del registro de cargo. Según un aspecto de la presente invención, el sistema también puede recanalizar cargos tal como empleando un mecanismo poner en cola para partida. Por ejemplo, si una bandera particular se establece en el sistema, entonces el código de cargo asincrónico no solicitará la liquidación inmediata de la cuenta. En su lugar, el cargo registrado se puede liq uidar vía un procesamiento de pago por partida regular en un día o entonces según las preferencias del proveedor de servicio o comerciante (por ejemplo, preferencias por partida de visita). Por lo tanto, la liquidación inmediata de la facturación de umbral se puede parar en caso de posibles problemas tales como cuando el proveedor de pagos no se puede conectar para la liquidación inmediata. Otras opciones con las cuales un comerciante puede liquidar el cargo del cliente incluyen un procesamiento sincrónico o inmediato y/o discontinuo (por ejemplo, junto con otros cargos). El comerciante, por ejemplo, puede potencialmente elegir cualquiera de las opciones de arriba, dependiendo del perfil del cliente, producto que se vende, el arrendatario de venta, etc. Se entiende que si los cargos acumulados no alcanzan un umbral dentro de un periodo de tiempo particular (por ejemplo, 30 días), entonces el comerciante o proveedor de servicio puede volver a hacer un cargo al cliente en una base mensual, por ejemplo. Pasando ahora a la Fig. 3, se ilustra un diagrama esquemático de varios factores típicos que pueden influir en la determinación de un valor de recurso de umbral 300. Por ejemplo, el tipo de recurso que se utiliza o compra por el cliente (tipo de recurso 310) así como el volumen de uso de aquel recurso ( volumen de recurso 320) puede influencia en el ajuste del valor de umbral 300. Una canción, por ejemplo, es un tipo de recurso que se puede "usar" por un cliente (por ejemplo, descargado). Canciones descargables pueden ser relativamente baratas por canción. Además, se pueden descargar en cantidades relativamente grandes por un solo cliente.

Por eso, el umbral se puede establecer lo suficientemente alto para permitir múltiples acontecimientos de cualquier número de descargas (por acontecimiento) antes de que el pago se requiera. A la inversa, si el tipo de recurso se refiere a mercancías valoradas más altas tal como automóviles, entonces el umbral se puede establecer lo suficientemente alto para permitir al cliente comprar al menos un automóvil, pero suficientemente bajo para no permitir la compra de dos carros antes de que el pago se requiera (por ejemplo, el comerciante puede querer permitir al cliente comprar y pagar por únicamente uno vehículo al mismo tiempo). Es este caso particular, el volumen puede o no puede ser un factor considerado por el comerciante al menos que otros parámetros se consideren tal como el instrumento de pago 330 (por ejemplo, tarjeta de crédito contra cuenta de valor almacenada), realimentación del proveedor de pagos 340 (por ejemplo, el cliente tiene una historia o rango de crédito bueno con la tarjeta de crédito o el banco), y/o la historia y/o uso histórico del cliente con el proveedor de servicio o comerciante 350 (por ejemplo, la relación del cliente con el comerciante). Por ejemplo, el umbral se puede establecer más alto cuanto el instrumento de pago es una cuenta de valor almacenada lo que significa que el cliente tiene un crédito con el comerciante. Sin embargo, el valor de umbral se puede establecer más bajo, si el instrumento de pago es una tarjeta de crédito y el banco lo ha comentado (a través de realimentación para el comerciante) que el cliente ha tenido 2 pagos atrasados en los últimos 4 ciclos de facturación, por ejemplo.

Además, el umbral de mercancías de bajo costo se puede establecer lo suficientemente alto para permitir a un cliente descargar o comprar varios artículos antes de que el umbral se alcance, en tanto que el umbral para mercancías de alto costo se puede establecer lo suficientemente alto para permitir una compra de uno o dos artículos antes de que el pago se requiera. Por lo tanto, los valores de umbral varían entre comerciantes 360 así como entre tipos 31 0 de recursos que se ofrecen por cualquier comerciante. Debido a que algunos proveedores de servicio o comerciantes pueden ofrecer una pluralidad de mercancías y servicios, el valor de umbral también puede fluctuar basándose en parte en un uso de recurso actual o suscripciones actuales del cliente. Por ejemplo, un cliente con un valor de umbral de $1 00 para W productos también desea comprar K servicios del comerciante R. El comerciante R puede establecer un umbral más alto para K servicios para el cliente basándose en el umbral relativamente alto que el cliente ya tiene para W productos. A la inversa, un cliente con un valor de recurso de umbral de únicamente $10 para W no puede, recibir tal umbral alto (por ejemplo, $1 00) para K servicios . Por eso , el contexto del cliente se analiza para facilitar la determinación de un valor de recurso de umbral apropiado. Finalmente, el periodo 370 puede ser un parámetro adicional empleado para comerciantes y proveedores de servicio. Por ejemplo, algunos comerciantes y proveedores de servicio se pueden arriesgar menos contrario durante temporadas de compra altas tal como meses de fiestas populares (por ejemplo, Noviembre y Diciembre). Como resultado, los valores de umbral se pueden establecer más altos durante estos meses. Por otra parte, los comerciantes se pueden arriesgar más contrario a los meses siguientes a una temporada de compra difícil tal como Enero y Febrero. Por lo tanto, los umbrales se pueden establecer más bajos para ese periodo. De forma alternativa o además, los umbrales más altos se puede establecer para coincidir con los periodos de pago del cliente tal como ser más altos al comienzo del mes (por ejemplo, recibir cheque de pago) y más bajos al final del mes (por ejemplo después de pagar las cuentas, queda menos dinero). Se considera que otros parámetros además de aquellos discutidos se pueden emplear en la determinación de los valores de recurso de umbral. También se considera que cualquier o combinación de parámetros se puede utilizar para determinar un valor de umbral actual. Varias metodologías de acuerdo con la invención sujeto ahora se describirán a través de una serie de acciones. Se comprende y considera que la presente invención no se limita por el orden las acciones, ya que algunas acciones pueden, de acuerdo con la presente invención, suceder en diferente orden y/o comúnmente con otras acciones de aquellas que se muestran y describen en la presente. Por ejemplo aquellos expertos en la materia comprenderán y considerarán que una metodología alternativamente se puede representar como una serie de condiciones o acontecimientos estrechamente ligadas, tal como en un diagrama de estado. Además no todos las acciones ilustradas se pueden requerir para implementar una metodología de acuerdo con la presente invención. Pasando ahora a la Fig. 4 se muestra un diagrama de flujo de un método típico 400 que facilita la consolidación de uso de recurso para mejorar los esquemas de facturación en línea. Según la invención sujeto, la entrada que se relaciona con un acontecimiento (datos de acontecimiento) tal como una compra y/o una descarga de mercancías o servicios se somete por un cliente, por ejemplo. En 410, el uso de recurso se detecta y/o determina (por ejemplo identificado y/o cuantificado), procesando y/o analizando los datos de acontecimiento. El uso de recurso se asocia con un tipo de recurso en 420. En 430, se puede determinar si el tipo de recurso se somete a un valor de recurso de umbral. Por eso, no cada tipo de recurso se somete a un esquema de facturación de umbral (por ejemplo, pago inmediato al alcanzar un umbral, se requiere) cuando se determina por las preferencias del comerciante. Por ejemplo, algunos minoristas en línea pueden requerir pago inmediato sobre una base por artículo para ciertas mercancías o servicios mientras en otras mercancías, los límites de facturación de umbral se establecen para permitir la consolidación de compras sobre un periodo de tiempo antes de que al cliente realmente se le haga un cargo de tal compra. De forma similar, algunos minoristas puede preferir mantener la facturación sobre una base mensual para algunas mercancías o servicios. Por ejemplo, un periódico en línea puede preferir facturar a sus clientes sobre una base mensual ya que el acceso y/o tiempo pasado conectado al periódico es ilimitado por mes. Por consiguiente, múltiples conexiones en cualquier periodo de un mes se puede transferir dentro de los términos de uso de recurso (por ejemplo, número de conexiones, número de minutos pasados conectado); sin embargo en este escenario, el caso de tipo de recurso asociado no se somete a un valor de recurso de umbral. Las Figs. 5-7 representan una serie de diagramas de flujo que representan procesos típicos que facilitan la identificación y rastreo del uso de recurso, correlacionando el uso actual con el uso anterior y entonces hacer el cargo a un cliente por la cantidad total de recursos usados cuando un valor de recurso de umbral se alcanza. Cualquier objeto, artículo, o servicio que se compra o usa por un cliente por una cuota se puede considerar un recurso. Por eso, el uso de recurso se refiere al uso de un recurso particular, en donde tal uso se puede transferir o convertir a un valor monetario para propósitos de facturación. Algunos recursos se pueden valorar (por ejemplo, asignar a un valor monetario o a una unidad de consumo) cuando se hace disponible para el cliente. A la inversa, algunos otros recursos se pueden no valorar cuando se hace disponible para consumo o uso del consumidor. En estos casos, el valor de recursos no valorados se puede determinar o revelar cuando el valor de recurso de umbral se alcanza. En referencia ahora la Fig. 5, se ilustra un diagrama de flujo de un método 500 que facilita la identificación y rastreo del uso de recurso por un cliente de acuerdo con un aspecto de la presente invención. El método 500 implica determinar que el uso de recurso se someta a consolidación de uso de recurso y facturación de umbral 510. En 520, el uso de recurso se puede registrar al saldo de recurso del cliente respectivo. El saldo de recurso se puede leer y entonces valorar o convertir para calcular un valor total del saldo de recurso en 530. Por ejemplo, un valor monetario del saldo de recurso se puede averiguar. En 540, el método 500 puede determinar, sí el valor total del saldo de recurso (por ejemplo, valor monetario o valor de unidad de consumo) al menos alcanza el valor de recurso de umbral para autorizar hacer le cargo al cliente (por ejemplo, por el valor total del saldo de recurso). De forma alternativa o además, el usuario también se puede notificar por un componente de notificación que su saldo de recurso esta alcanzando el valor de recurso de umbral dentro de una escala fija. Por ejemplo, el método 500 se puede programar para enviar una notificación al usuario cuando el usuario esta dentro de Q unidades de su saldo o valor de recurso de umbral particular. En este caso, el pago o liquidación de la cuenta del cliente se puede requerir antes de que el saldo o valor de recurso de umbral realmente se alcance. Esto puede ser aplicable para aquellos usuarios los cuales pagan por cargo a cuenta directo o por pago obligatorio (por ejemplo, Japón). Asumiendo que el valor total alcanza el valor de recurso de umbral en la Fig. 5, el método 600 puede seguir de ahí para efectuar el pago o liquidación para recursos que han sido "comprados" pero que aún no se paga por ellos. El método 600 incluye escribir la cantidad de cargo o cargo a cuenta total a una base de datos tal como una fila no local o memoria intermedia sin restricción que también sirve como un área de consolidación y almacenamiento para los recursos "comprados" (en 610). La base de datos puede operar como un depósito poseedor para tales compras hasta que el total de las compras se determina para al menos alcanzar el valor de recurso de umbral. En 620, una solicitud de cargo o cargo a cuenta asincrónico se puede poner en fila en un sistema PF para llevara a cabo al menos una liquidación parcial de la cuenta del cliente (por ejemplo, hasta el punto que el saldo de recurso cae por debajo del valor de recurso de umbral). Acciones adicionales que se puede tomar por el sistema MPF se discuten en la Fig. 7, infra. En 630, la cuenta de recurso del cliente se puede reajustar a algún valor tal como cero, por ejemplo, para indicar que compras o uso de recurso anteriores se han pagado y que actualmente, no se han "comprado" recursos por el cliente o acumulado con respecto al valor de recurso de umbral. En 640, un mensaje, por ejemplo, se puede enviar al comerciante o proveedor de servicio (por ejemplo, partida de visita) de que el uso de recurso del cliente se ha registrado en la base de datos. Dependiendo del comerciante o preferencias del proveedor de servicio, la cuenta de recurso del cliente se pude colocar en espera hasta q ue el pago se confirme. De forma alternativa, algunos comerciantes pueden permitir a algunos de sus mejores clientes hacer uso de una cantidad pequeña de recursos hasta que el pago se verifique y confirme. Por ejemplo, un mejor cliente puede ser un cliente el cual ha suministrado de forma histórica pagos oportunos con pocos si cualquier cargo falla. En referencia ahora a la Fig . 7, se ilustra un diagrama de flujo de un método típico 700 para procesar una solicitud de cargo de acuerdo con un aspecto de la presente invención. La llamada de q ue la solicitud de cargo se puede hacer tan pronto como un valor de recurso de umbral se alcanza (ver Fig. ñ.supra). El método puede estar alrededor de 71 0, en donde una acción o solicitud de cargo pendiente se recoge de la memoria intermedia o base de datos respectiva; un código de cargo apropiado para ejecutar se encuentra o localiza y el código se llama. En 720, el registro de cargo (saldo de recurso) se puede leer de la base de datos para intentar la liquidación de al menos una parte del cargo total contra el proveedor de pagos designado. Si el cargo es exitoso (por ejemplo, el pago se asegura del proveedor de pagos) en 730, entonces se puede registrar como un cargo exitoso en la base de datos respectiva en 740. El cliente también se puede notificar de que el pago se hizo (por ejemplo, vía un componente de notificación). Sin embargo, si el cargo falla y el pago solicitado se rechaza en 730, entonces la negativa se registra en la base de datos respectiva en 750. Un reintento para procesar el cargo se puede programar en 760 y la cuenta del cliente (por ejemplo, capacidades de compra, acceso a servicio de suscripción) se puede suspender hasta que el cargo es exitoso. Como resultado de la suspensión de la cuenta, una notificación también se puede enviar al comerciante o proveedor de servicio de que cualquiera de las capacidades de compra o servicios se deben al menos temporalmente impedir en 770. Se comprende que en cualquier escenario en donde el pago o liquidación de la cuenta del usuario sea fallida, un umbral de suspensión se puede pedir. Por ejemplo, el umbral de suspensión puede referirse a una cantidad o valor de uso por la cual el pago no se ha recibido. De forma alternativa o adicionalmente, el umbral de suspensión puede corresponder a un número de veces que el pago ha sido solicitado pero se ha rechazado por el proveedor de pagos (por ejemplo, tarjeta de crédito, banco, etc.). Además, en lugar de múltiples transacciones de cargo, compras y/o cargo se consolidan esencialmente en menos transacciones de cargo, lo cual resulta en mitigar los costos generales de transacción (por ejemplo, cuotas de tarjeta de crédito) así como el tiempo del consumidor. En la práctica, imagina un minorista de descarga de música que suministra un servicio de descarga de música. Para mejorar las experiencias del cliente, los clientes pueden comprar y descargar canciones sin ser impedidos por un proceso de cargo al final de cada compra. Por ejemplo, en un escenario convencional, el procedimiento de pago puede ocasionar una o dos páginas web extra así como un cuantos segundos para hacer el cargo en la tarjeta de crédito del cliente. Para clientes los cuales constantemente regresan a comprar un par de canciones nuevas, unas cuantas canciones más una hora después, aún más canciones 20 minutos después, y luego aún más el día siguiente, trabajar a través del proceso de pago para cada compra puede ser tedioso y puede requerir mucho tiempo. Simplemente el cargo por día o por mes para compras acumuladas puede ser muy riesgoso ya que esto puede permitir que un cliente descargue una cantidad grande de canciones antes de que el minorista descubra que el/ella no puede pagar por aquellas canciones descargadas. En este punto, el uso además inválido del servicio no necesariamente mitiga pérdidas económicas y riesgo de deuda morosa. Además, en el caso de artículos descargados, el cliente ya ha recibido el beneficio de la compra y puede ser casi imposible recuperar tales artículos. Según la presente invención, sin embargo, las perdidas económicas potenciales y el riesgo de deuda morosa se puede mitigar al menos hasta el punto del nivel de umbral. Debido a que la presente invención emplea un mecanismo de cargo asincrónico, tarjetas de crédito del cliente, por ejemplo, se pueden cargar en cualquier momento cuando el umbral respectivo se alcanza sin incrementar el estado latente de visita para los comerciantes/minoristas (por ejemplo, entidades de visita) que están reportando y registrando las compras. En referencia otra vez al ejemplo de servicio de música de arriba, en donde grandes cantidades de canciones se puede comprar y descargar por cualquier cliente, la presente invención hace uso de una memoria intermedia sin restricción para manejar de forma potencial compras de gran volumen a través de la consolidación y para correlacionarlas con compras consolidadas anteriormente hasta que el umbral se alcanza. Tan pronto como el umbral se alcanza, sin tener en cuenta el valor de umbral particular, al cliente se le puede hacer un cargo de forma asincrónica. El umbral puede corresponder a un uso de recurso (por ejemplo, cantidad de recursos utilizados, comprados o consumidos por el cliente) por medio del cual el uso del consumidor de un recurso se registra. Una vez que un umbral de uso de recurso se alcanza, una fórmula se puede usar para convertir el uso de recurso a un valor monetario y que la cantidad se cargue al proveedor de pagos del cliente. En este escenario, los recursos (por ejemplo, presentados en la forma de una oferta o acontecimiento) no se asocian inmediatamente con un valor monetario (por ejemplo, no pre-valorados). De forma alternativa, el umbral se puede relacionar directamente a un valor monetario. Por ejemplo, el umbral se puede establecer en $25 para que cuando el cliente gasta hasta $25. en recursos, un pago inmediato de $25 se solicite. En este caso, los recursos se pre-valorarán o asociaran con un costo cuando se presenten al cliente. La invención sujeto se puede llevar a cabo en parte empleando una visita de Acontecimiento de Uso de Reporte como se ilustra esquemáticamente en la gráfica de flujo típica 800 de la Fig.8.

La visita de Acontecimiento de Uso de Reporte facilita el reporte y/o registro del uso de recurso para un saldo de recurso (periodo total) del cliente hasta que el umbral se alcanza. En esquemas de facturación convencionales, el saldo de recurso total del periodo se mantendría sobre una base mensual, por ejemplo, si el cliente se facturará en una base por mes. Como se puede ver en la gráfica de flujo 800 en la Fig. 8. , la visita de Acontecimiento de Uso de Reporte opera en conexión con un sistema (instalación de procesamiento de mensajes) MPF, el cual es similar a una fila de mensaje, para obtener la liquidación inmediata de la cuenta del cliente tan pronto como el valor de umbral se alcanza. Para suministrar el contexto adicional para varios aspectos de la presente invención, la Fig. 9 y la siguiente discusión tiene la intención de suministrar una breve, descripción general de un ambiente de operación conveniente 910, en la cual varios aspectos de la presente invención se pueden impiementar. Aunque la invención se describe en el contexto general de instrucciones ejecutables de la computadora, tal como módulos de programa, ejecutados por una o más computadoras u otros mecanismos, aquellos expertos en la materia reconocerán que la invención también se puede impiementar en combinación con otros módulos de programa y/o como una combinación de hardware y software. Generalmente, sin embargo, los módulos de programa incluyen rutinas, programas, objetos, componentes, estructuras de datos, efe , que pueden llevar a cabo tareas particulares o implementar tipos de datos particulares. El ambiente de operación 910 es únicamente un ejemplo de un ambiente de operación conveniente y no tiene la intención de sugerir cualquier limitación en cuanto al ámbito de uso o funcionalidad de la invención. Otros sistemas de computadora bien conocidos, ambientes y/o configuraciones que pueden ser convenientes para uso con la invención incluyen pero no se limitan, computadoras personales, mecanismos de laptop o portátil, sistemas de multiprocesador, sistemas basados en microprocesador, electrónicos de consumidor programables, PCs de rede, microcomputadoras, computadoras maestras, ambientes de computación distribuidos que incluyen los mecanismos o sistemas de arriba, y lo similar. Con referencia a la Fig. 9, un ambiente típico 910 para implementar varios aspectos de la invención incluye una computadora 912. La computadora 912 incluye una unidad de procesamiento 914, una memoria de sistema 916, y un bus de sistema 918. El bus de sistema 918 conecta los componentes de sistema que incluyen, pero no se limita, la memoria de sistema 916 a la unidad de procesamiento 914. La unidad de procesamiento 914 puede ser cualquiera de varios procesadores disponibles. Los microprocesadores dobles y otras arquitecturas de microprocesador también se puede emplear como la unidad de procesamiento 914. El bus de sistema 918 puede ser cualquiera de varios tipos de estructura(s) bus que incluyen la memoria bus o memoria controladora, un bus periférico o bus externo, y/o un bus local que usa cualquier variedad de arquitecturas bus disponible que incluyen, pero no se limitan, bus de 1 1 bites, Arquitectura Estándar Industrial (ISA), Arquitectura de Micro-Canal (MSA), ISA Extendida (EISA), Electrónicos de Disco Inteligentes (IDE), Bus Local VESA (VLB), Interconector de Componente Periférico (PCI), Bus Serial Universal (USB), Puerto de Gráficos Avanzados (AGP), bus de Asociación Internacional de Tarjeta de Memoria de Computadora Personal (PCMCIA), e Interface de Sistemas de Computadora Pequeños (SCSI). La memoria de sistema 916 incluye memoria volátil 920 y memoria no volátil 922. El sistema de entrada/salida básico (BIOS), que contiene las rutinas básicas para transferir información entre los elementos dentro de la computadora 912, tal como durante el arranque, se almacena en memoria no volátil 922. Para ilustración, y no limitación, la memoria no volátil 922 puede incluir leer únicamente la memoria (ROM), ROM programable (PROM), ROM eléctricamente programable (EPROM), ROM eléctricamente borrable (EEPROM), o memoria flash. La memoria volátil 920 incluye memoria de acceso aleatorio (RAM), la cual actúa como memoria inmediata externa. Para ilustración y no limitación, RAM esta disponible en muchas formas tal como RAM sincrónica (SRAM), RAM dinámica (DRAM), DRAM sincrónica (SDRAM), SDRAM de doble escala de datos (DDR SDRAM), SDRAM aumentada (ESDRAM), DRAM EnlaceSinc (SLDRAM), y RAM Rambus directa (DRRAM). La computadora 912 también incluye un medios de almacenamiento de computadora volátil/no volátil, móvil/ no móvil. La Fig. 9 ¡lustra, por ejemplo un disco de almacenamiento 924. El disco de almacenamiento 924 incluye, pero no se limita, mecanismos como un disco magnético, disco floppy, disco de cinta, disco Jaz, disco Zip, disco LS-100, tarjeta de memoria flash, o barra de memoria. Además, el disco de almacenamiento 924 puede incluir medios de almacenamiento de forma separada o en combinación con otros medios de almacenamiento que incluyen, pero no se limitan, un disco óptico tai como un mecanismo ROM de disco compacto (CD-ROM), disco regrabable CD (CD-R Drive), disco reescribible CD (CD-RW Drive) o un disco ROM de disco versátil digital (DVD-ROM). Para facilitar la conexión de los mecanismos del disco de almacenamiento 924 al bus de sistema 918, una interface no móvil o móvil, se típicamente usa, tal como interface 926. Se comprende que la Fig. 9 describe un software que actúa como un intermediario entre los usuarios y los recursos de computadora básicos descritos en el ambiente de operación conveniente 91 0. Tal software incluye un sistema de operación 928. El sistema de operación 928, el cual se puede almacenar en un disco de almacenamiento 924, actúa para controlar y asignar recursos del sistema de computadora 912. Las aplicaciones del sistema 930 toman ventaja del manejo de los recursos por el sistema de operación 928 a través de módulos de programa 932 y datos de programa 934 almacenados ya sea en memoria del sistema 916 o en un disco de almacenamiento 924. Se comprende que la presente invención se puede implementar con varios sistemas de operación o combinaciones de sistemas de operación. Un usuario mete comandos o información en la computadora 912 a través de un mecanismo(s) de entrada 936. Los mecanismos de entrada 936 incluyen, pero no se limitan, un mecanismo de señalización tai como un mouse, bola, estilete, plataforma de contacto, teclado, micrófono, palanca de juegos, plataforma de juego, escáner, antena satelital, tarjeta sintonizadora de TV, cámara digital, video cámara digital, cámara web, y lo similar. Estos y otros mecanismos de entrada se conectan a la unidad de procesamiento 914 a través del bus de sistema 91 8 vía puerto (s) de interface 938. Puerto(s) de interface 938 incluye, por ejemplo, un puerto serial, un puerto paralelo, un puerto de partida, y un bus serial universal (USB). Mecanismo(s) de salida 940 usan algunos del mismo tipo de puertos como mecanismo(s) de entrada 936. Por eso , por ejemplo, un puerto USB se puede usar para suministrar una entrada a la computadora 912, y para sacar información de la computadora 912, a un mecanismo de salida 940. El adaptador de salida 942 se suministra para ilustrar que hay algunos mecanismos de salida 940 como monitores, bocinas, e impresoras entre otros mecanismos de salida 940 que req uieren adaptadores especiales. Los adaptadores de salida 942 incluyen , para ilustración y no limitación, tarjetas de sonido y video que suministran un medio de conexión entre el mecanismo de salida 940 y el bus de sistema 91 8. Se observa que otros mecanismos y/o sistemas de mecanismos suministran ambas capacidades de entrada y salida tal como computadora(s) remotas 944. La computadora 912 puede operar en un ambiente de redes que usa conexiones lógicas para una o más computadoras remotas, tal como computadora(s) remota 944. Computadora(s) remota 944 puede ser una computadora personal, un servidor, un ruteador, un PC de red , una estación de trabajo, una dispositivo basado en microprocesador, un mecanismo par u otro nodo de red común y lo similar, e incluye típicamente muchos o todos de los elementos descritos relativos a la computadora 91 2. Con propósitos de brevedad, únicamente un mecanismo de almacenamiento de memoria 946 se ilustra con computadora(s) remota 944. Computadora(s) remota 944 es conecta lógicamente a la computadora 912 a través de una interface de red 948 y entonces se conecta físicamente vía conexión de comunicación 950. La interface de red 948 abarca redes de comunicación tales como redes de área local (LAN) y redes de área amplia (WAN). Tecnologías LAN incluyen Interface de Datos Distribuida de Fibra (FDDI), Interface de Datos Distribuida de Cobre (CDDI), Ethernet/IEEE 1 102.3, Token Ring/IEEE 1 102.5, y lo similar. Tecnologías WAN incluyen , pero no se limitan, vínculos punto a punto, redes de cambio de circuito como Redes Digitales de Servicios I ntegrados (ISDN) y variaciones de los mismos, redes de cambio de paq uete, y Líneas de Suscriptor Digital (DSL). Conexión(es) de comunicación 950 se refiere al hardware/software que se emplea para conectar la interface de red 948 al bus 918. Aunque la conexión de comunicación 950 se muestra para claridad ilustrativa dentro de la computadora 912, también puede ser externa a la computadora 912. El hardware/software necesario para la conexión a la interface de red 948 incluye, para propósitos de ejemplo únicamente, tecnologías externas e internas tal como, módems que incluyen módems de clase para teléfono regular, módems de cable y módems DSL, adaptadores ISDN, y tarjetas de Ethernet. Lo que se ha descrito arriba incluye ejemplos de la presente invención. Por supuesto, no es posible describir cada combinación concebible de componentes o metodologías con el propósito de describir la presente invención, pero uno de ordinaria experiencia en la materia puede reconocer que muchas otras combinaciones y permutaciones de la presente invención son posibles. Por consiguiente, la presente invención tiene la intención de abarcar todas tales alteraciones, modificaciones y variaciones que caen dentro del espíritu y ámbito de las reivindicaciones anexas. Además, hasta este punto el término "incluye" se usa en ya sea la descripción detallada o las reivindicaciones, tales términos tienen la intención de estar inclusive en un modo similar al término "comprende" así como "consiste" se interpreta cuando se emplea como una palabra de transición en una reivindicación.

Claims (1)

1. REIVI NDICACIONES 1 . Un sistema de cargo a cuenta que comprende: un componente de detección q ue detecta acontecimientos iniciados por una entidad para determinar si tales acontecimientos se someten a un valor de recurso de umbral; y un componente de cargo a cuenta que hace un cargo a la entidad en al menos una subserie de los acontecimientos que alcanzan el valor de recurso de umbral. 2. El sistema según la reivindicación 1 , caracterizado porque los acontecimientos son uno de pre-valorado o no pre-valorado. 3. El sistema según la reivindicación 1 , caracterizado porq ue el valor de recurso corresponde a un valor monetario. 4. El sistema seg ún la reivindicación 1 , caracterizado porque el valor de recurso corresponde a una unidad de consumo. 5. El sistema según la reivindicación 1 , los acontecimientos q ue se refieren a al menos una compra. 6. El sistema según la reivindicación 1 , los acontecimientos comprenden de uno o más recursos para uso por una entidad por medio del la cual el componente de detección detecta si tales recursos se someten al valor de recurso de umbral. 7. El sistema seg ún la reivind icación 1 , los acontecimientos comprenden al menos un primer acontecimiento, el primer acontecimiento comprende al menos un primer recurso, el primer recurso tiene al menos uno de un valor monetario y un valor de unidad de consumo. 8. El sistema según la reivindicación 7, los acontecimientos comprenden al menos un segundo acontecimiento, el segundo acontecimiento es diferente del primer acontecimiento, el segundo acontecimiento comprende al menos un segundo recurso, el segundo recurso es diferente del primer recurso y tiene al menos uno de valor monetario y un valor de unidad de consumo que es diferente del primer recurso. 9. El sistema según la reivindicación 1 , caracterizado porque cualquier acontecimiento consta de una pluralidad de diferentes recursos que tienen una pluralidad de diferentes valores monetarios o valores de unidad de consumo. 10. El sistema según la reivindicación 1 , la entidad es un cliente, el cliente es cualquiera de un individuo, más de una persona, una compañía, y una máquina. 1 1 . El sistema según la reivindicación 1 , además comprende un componente de rastreo que correlaciona un acontecimiento actual con acontecimientos anteriores para rastrear el uso de recurso hasta que el valor de recurso de umbral se alcanza. 12. El sistema según la reivindicación 1 , el componente de cargo a cuenta solicita el pago del proveedor de pagos de la entidad cuando el valor de recurso de umbral al menos se alcanza. 13. El sistema según la reivindicación 1 , caracterizado porque acontecimientos que entran al componente de detección se suspenden al menos hasta que la notificación de que el pago se hizo se recibe para mitigar perdidas económicas. 14. El sistema según la reivindicación 1 , además comprende un componente de notificación que notifica a la entidad de al menos uno de los siguientes: que el pago se ha hecho; que el pago no se ha hecho; que la entidad se suspende de otro uso; y que el valor de recurso de umbral está en Q unidades, caracterizado porque Q es un número entero mayor o igual a uno. 15. El sistema según la reivindicación 1 , además comprende un componente interrogante que permite a un componente externo determinar un estado de la cuenta de la entidad relativo al valor de recurso de umbral. 16. Un sistema que facilita la compra en línea y el manejo de cuenta que comprende: un componente que determina si el uso de recurso se asocia con un cargo de umbral; un componente de registro de uso de recurso que registra el uso de recurso; un componente de análisis que compara el uso de recurso acumulado con un valor de recurso de umbral para determinar si el valor de recurso de umbral se alcanza; y un componente de pago que solicita el pago para el uso de recurso cuando el valor de recurso de umbral se alcanza. 17. El sistema según la reivindicación 16, además comprende un saldo de recurso que se refiere a un periodo total del uso de recurso, por medio del cual el uso de recurso adicional se agrega al saldo de recurso, el cual se compara con el valor de recurso de umbral para determinar si se solicita el pago por recursos utilizados hasta ahora. 18. El sistema seg ún la reivindicación 16 , además comprende un componente q ue consolida al menos un acontecimiento anterior de uso de recurso con un acontecimiento actual de uso de recurso. 1 9. El sistema según la reivindicación 16, además comprende una base de datos operativamente conectada al registrador de uso de recurso que almacena al menos una de los registros de compra, registros de pago, registros de compra total, y registros de uso de recurso. 20. El sistema según la reivindicación 19, la base de datos es una fila no local . 21 . El sistema según la reivindicación 1 9, la base de datos es una memoria intermedia sin restricción que puede almacenar cualquier cantidad de recursos utilizados o comprados. 22. El sistema según la reivindicación 1 6, además comprende un componente que procesa las solicitudes de pago recibidas del componente de pago y q ue suspende cuentas por las cuales la solicitud de pago se rechazó. 23. El sistema según la reivindicación 22, el componente es una instalación de procesamiento de mensaje. 24. El sistema según la reivindicación 16, el valor de recurso de umbral se basa al menos en parte en uno o más de los siguientes factores: tipo de recurso; volumen de recurso; instrumento de pago; realimentación del proveedor de pagos; uso de recurso histórico de entidad; historia de pagos; preferencias del proveedor de mercancías o servicios; preferencias de entidad; y periodo de uso de recurso. 25. El sistema según la reivindicación 16, el valor de recurso de umbral se ajusta periódicamente o aleatoriamente y manualmente o automáticamente. 26. Un método que facilita la facturación de umbral que comprende: detectar que al menos un primer acontecimiento se ha iniciado por una entidad; determinar que el primer acontecimiento se somete a un valor de recurso de umbral; registrar el uso de recurso correspondiente al primer acontecimiento para un saldo de recurso respectivo mantenido en una base de datos; y determinar si los saldos de recurso alcanzan el valor de recurso de umbral. 27. El método según la reivindicación 26, además comprende enviar una solicitud de pago a un proveedor de pagos cuando el valor de recurso de umbral se alcanza; y registrar la solicitud de pago a la base de datos. 28. El método según la reivindicación 27, además comprende reajustar el saldo de recurso respectivo cuando la solicitud de pago se envía. 29. El método según la reivindicación 27, la solicitud de pago consta de al menos una parte de una cuota de la cantidad. 30. El método según la reivindicación 29, la cuota de la cantidad corresponde al menos a una parte del uso de recurso o el saldo de recurso. 31 . El método según la reivindicación 27, que inicia la solicitud de pago que comprende: localizar el código de cargo correspondiente a la solicitud de pago pendiente, la solicitud de pago se asocia con un registro de cargo; llamar al código de cargo; leer el registro de cargo; e intentar la liquidación de la solicitud de pago contra el proveedor de pagos. 32. El método según la reivindicación 27, además comprende suspender el acceso a recursos cuando la solicitud de pago del proveedor de pagos se rechaza. 33. El método según la reivindicación 27, la base de datos es cualquiera de los siguientes: una fila no local y una memoria intermedia sin restricción capaces de guardar numerosos acontecimientos hasta que el valor de recurso de umbral se alcanza. 34. El método según la reivindicación 32, además comprende programar al menos un intento posterior para satisfacer la solicitud de pago. 35. El método según la reivindicación 27, comprende registrar la solicitud de pago. 36. Un sistema que facilita la facturación de umbral que comprende: medio para detectar que al menos un primer acontecimiento se ha iniciado por una entidad; . medio para determinar que el primer evento se somete a un valor de recurso de umbral; medio para registrar el uso de recurso correspondiente a el primer acontecimiento para un saldo de recuso respectivo; y medio para determinar si el saldo de recurso alcanza el valor de recurso de umbral. 37. El método según la reivindicación 36, además comprende medio para enviar una solicitud de pago al proveedor de pagos cuando el valor de recurso de umbral se alcanza. 38. Una medio legible por computadora que tiene almacenado en él los componentes ejecutables por computadora, los componentes comprenden: un componente de detección que detecta acontecimientos sometidos por una entidad para determinar si tales acontecimientos se someten a un valor de recurso de umbral; y un componente de cargo a cuenta que hace un cargo a la entidad sobre al menos una subserie de los acontecimientos que alcanzan el valor de recurso de umbral. 39. Un medio legible por computadora que tiene almacenado en él los componentes ejecutables por computadora, los componentes comprenden: un componente que determina si el uso de recurso por una entidad se somete a un cargo de umbral; un componente registrador de uso de recurso que registra el uso de recurso; un componente de análisis que compara el uso de recurso acumulado con un valor de recurso de umbral para determinar si el valor de recurso de umbral se alcanza; y un componente de pago que solicita el pago para el uso de recurso cuando el valor de recurso de umbral se alcanza. 40. Un paquete de datos adaptado para transmitirse entre dos o más procesos de computadora que facilitan identificar correos basura potenciales, el paquete de datos comprende: información asociada con determinar si el uso de recurso se asocia con un cargo de umbral, caracterizado porque el uso de recurso se registra y analiza para averiguar si el uso de recurso acumulado alcanza un valor de recurso de umbral; e información correspondiente a una solicitud para el pago para el uso de recurso cuando el valor de recurso de umbral se alcanza.