BRPI0619481A2

BRPI0619481A2 - sistema e/ou método para levantamento de preços

Info

Publication number: BRPI0619481A2
Application number: BRPI0619481-8A
Authority: BR
Inventors: Shabbir Khan; Alexander Cohen
Original assignee: Lippershy Celestial Llc
Priority date: 2005-12-06
Filing date: 2006-12-06
Publication date: 2011-10-04
Also published as: CN101411129A; US20070133570A1; KR20080086471A; US7720073B2; JP2009518974A; JP4825877B2; EP1964334A2; WO2007067930A3; EP1964334A4; KR101106378B1; WO2007067930A2

Abstract

SISTEMA E/OU MéTODO PARA LEVANTAMENTO DE PREçOS. A presente invenção refere-se a sistemas e/ou aparelhos para transmitir objetos digitais para um destino. Em particular, são descritos sistemas e/ou aparelhos para facilitar o levantamento de preço para o negócio de enviar objetos digitais em uma rede de transmissão de dados.

Description

Relatório Descritivo da Patente de Invenção para "SISTEMA E/OU MÉTODO PARA LEVANTAMENTO DE PREÇOS"

PEDIDOS RELACIONADOS

O assunto descrito neste documento reivindica prioridade para o número de série 11/296.819 denominado SYSTEM AND/OR METHOD FOR BIDDING, possuindo uma data de depósito de 6 de dezembro de 2005, e é incorporado neste documento por referência.

CAMPO

O tema descrito neste documento relaciona-se com a transmis- são de objetos digitais em uma rede de transmissão de dados.

ANTECEDENTES

Os mecanismos de troca de informação utilizando a Internet têm sido disponibilizados grátis para vários serviços. Para enviar informação a partir de um nó-fonte para um nó-destino, uma ou mais partes intermediárias podem enviar a informação através de pelo menos uma parte de um cami- nho acoplando o nó-fonte com o nó-destino. Tais partes intermediárias tipi- camente possuem, alugam, controlam e/ou operam equipamento tal como roteadores e/ou similares para enviar informação de acordo com um protoco- lo de rede tal como o Protocolo Internet. As partes intermediárias incorrem em custos substanciais na implementação, manutenção e operação de equi- pamento para o propósito de enviar informações para um nó-destino.

BREVE DESCRIÇÃO DAS FIGURAS

Modalidades não limitativas e não exaustivas da presente inven- ção serão descritas com referência às figuras seguintes, onde números de referência iguais se referem a partes iguais por todas as várias figuras a não ser que de outro modo especificado.

A figura 1 é um diagrama esquemático de uma rede de trans- missão de dados de acordo com uma modalidade;

A figura 2 é um diagrama esquemático de um roteador que pode ser possuído, alugado, controlado e/ou operado por um intermediário para transmitir pelo menos uma parte de um objeto digital para um nó-destino de acordo com uma modalidade; A figura 3 é um diagrama esquemático de uma rede de trans- missão de dados para transmitir um objeto digital para dois ou mais nós- destino de acordo com uma modalidade;

A figura 4 é um fluxograma ilustrando um processo para iniciar a transmissão de um objeto digital a partir de um nó-fonte de acordo com uma modalidade;

A figura 5 é um fluxograma ilustrando um processo para atuar de acordo com uma requisição de orçamento recebida em um intermediário de acordo com uma modalidade;

A figura 6 é um diagrama esquemático de uma rede de trans- missão de dados para transmitir um objeto digital a partir de um nó-fonte, para um nó-destino, através de dois ou mais intermediários;

A figura 7 é um fluxograma ilustrando um processo para atuar de acordo com uma requisição de orçamento recebida em um intermediário, de acordo com uma modalidade;

A figura 8 é um diagrama esquemático de uma rede de trans- missão de dados compreendendo uma primeira rede para transmitir um ob- jeto digital a partir de um nó-fonte para um nó-destino, e uma segunda rede para facilitar o levantamento de preços entre os intermediários;

A figura 9 é um fluxograma ilustrando um processo para iniciar a transmissão de um objeto digital para um ou mais nós-déstino de acordo com uma modalidade da rede de transmissão de dados da Figura 8;

A figura 10 é um fluxograma ilustrando um processo para facilitar o levantamento de preços para o serviço de enviar um objeto digital para um ou mais nós-destino de acordo com uma modalidade da rede de transmissão de dados da Figura 8.

DESCRIÇÃO DETALHADA

A referência por todo o relatório descritivo a "uma modalidade" ou "a modalidade" significa que um aspecto, estrutura ou característica parti- cular, descritos em conexão com a modalidade, estão incluídos em pelo me- nos uma modalidade da presente invenção. Assim, os aparecimentos da frase "em uma modalidade" ou "a modalidade" em vários locais por todo este relatório descritivo não estão todos necessariamente se referindo à mesma modalidade. Além disso, os aspectos, estruturas, ou características podem ser combinados em uma ou mais modalidades.

Uma "rede de transmissão de dados" como referida neste do- cumento refere-se a infra-estrutura que é capaz de transmitir dados entre nós que estão acoplados com a rede de transmissão de dados. Por exem- plo, uma rede de transmissão de dados pode compreender ligações capazes de transmitir dados entre nós de acordo com um ou mais protocolos de da- dos. Tais ligações podem compreender um ou mais tipos de meio de trans- missão capazes de transmitir informação a partir de uma fonte para um des- tino. Entretanto, estes são meramente exemplos de uma rede de transmis- são de dados e o assunto reivindicado não está limitado e estes aspectos.

Na transmissão de dados em uma rede de transmissão de da- dos, um "nó-fonte" pode iniciar a transmissão de dados para um ou mais "nós-destino" acoplados com a rede de transmissão de dados. Em uma mo- dalidade particular, apesar do assunto reivindicado não estar limitado a este respeito, um nó-fonte pode iniciar a transmissão de dados para o nó-destino baseado, pelo menos em parte, em um endereço destino associado com o nó-destino. Aqui, de acordo com um protocolo de comunicação de uma mo- dalidade particular, o nó-fonte pode transmitir dados para o nó-destino em um ou mais "pacotes de dados", os quais são direcionados para o nó-destino através da rede de transmissão de dados baseada, pelo menos em parte, no endereço destino. Entretanto, estes são meramente exemplos de como os dados podem ser transmitidos a partir de um nó-fonte para um nó-destino em uma rede de transmissão de dados e o assunto reivindicado não está limitado a estes respeitos.

Um nó em uma rede de transmissão de dados pode "enviar" in- formação para um ou mais outros nós na rede de transmissão de dados a- través de ligações de dados. Em um exemplo particular, um primeiro nó po- de enviar informação para um segundo nó por transmitir um ou mais pacotes de dados de acordo com um protocolo de comunicação. Tais pacotes de dados podem compreender uma parte de cabeçalho contendo um endereço de um nó-destino pretendido e uma carga útil contendo a informação envia- da. Se o segundo nó não for o último destino pretendido, o segundo nó pode também enviar os pacotes de dados para um terceiro nó que compreende e/ou está acoplado com o nó-destino final pretendido. Entretanto, estes são meramente exemplos de como a informação pode ser enviada em uma rede de transmissão de dados e o assunto não está limitado a este respeito.

Um "objeto digital" como referido neste documento refere-se a informação que é organizada e/ou formatada em uma forma digitalizada. Por exemplo, um objeto digital pode compreender um ou mais documentos, mí- dia visual e/ou mídia de áudio, e/ou combinações dos mesmos. Entretanto, estes são meramente exemplos dos tipos de informações que podem ser mantidos em um objeto digital e o assunto reivindicado não está limitado a este respeito. Tal objeto digital pode ser mantido em um formato compacta- do para permitir o armazenamento eficiente do objeto digital em um meio de armazenamento e/ou a transmissão do objeto digital em uma rede de trans- missão de dados. Em outras modalidades, tal objeto digital pode ser cripto- grafado para transmissão em um canal de comunicação seguro. Em uma modalidade particular, apesar do assunto reivindicado não estar limitado a este respeito, um objeto digital pode ser formatado em um nó-fonte para transmissão para um ou mais nós-destino. Além disso, um objeto digital po- de ser transmitido para um ou mais nós-destino como um ou mais pacotes de dados direcionados para um ou mais nós de dados de acordo com um protocolo de comunicação. Entretanto, estes são meramente exemplos de um objeto digital e o assunto reivindicado não está limitado a este respeito.

Um "orçamento" como referido neste documento refere-se a uma expressão de uma proposta para executar um serviço. Em um exemplo particular, um freguês ou cliente pode receber orçamentos a partir de mais do que uma parte competindo para o negócio do freguês e/ou cliente. Um orçamento pode especificar termos sob os quais um serviço pode ser execu- tado tal como, por exemplo, preço, qualidade, pontualidade e/ou confiabili- dade. Entretanto, estes são meramente exemplos de termos que podem ser expressos em um orçamento e o assunto reivindicado não está limitado nes- te aspecto. Além disso, em alguns contextos comerciais, a aceitação de um orçamento por um freguês e/ou cliente pode ser levantamento de preços em relação às partes. Em outros contextos comerciais, entretanto, a aceitação de um orçamento por um freguês e/ou cliente, por si mesmo e de si mesmo, pode não ser levantamento de preços. Aqui, ações adicionais por uma ou mais partes podem resultar em uma disposição de levantamento de preços. Deve ser entendido que estes são meramente exemplos de um orçamento e o assunto reivindicado não está limitado neste aspecto.

Uma "requisição de orçamento" como referido neste documento refere-se a uma expressão de um convite para proporcionar um orçamento para executar um serviço. Em um exemplo particular, tal requisição de or- çamento pode especificar um serviço desejado a ser executado por um pro- vedor de serviço. Em algumas modalidades, a requisição de orçamento pode especificar alguns dos termos, mas não necessariamente todos os termos, sob os quais um serviço desejado é para ser executado. Entretanto, estes são meramente exemplos de uma requisição de orçamento e o assunto rei- vindicado não está limitado nestes aspectos.

Em resposta a recepção de um orçamento a partir de um prove- dor de serviço para proporcionar um serviço, um freguês e/ou cliente em po- tencial pode proporcionar uma "mensagem de aceitação" para o provedor de serviço que fez o levantamento de preço. Tal mensagem de aceitação pode expressar uma propensão do freguês e/ou cliente em receber os serviços a partir do provedor de serviço de acordo com pelo menos alguns termos ex- postos no orçamento recebido. Entretanto, isto é meramente um exemplo de uma mensagem de aceitação e o assunto reivindicado não está limitado nes- te aspecto.

De acordo com uma modalidade, duas ou mais partes podem trocar mensagens no curso de concordarem com os termos sob os quais um serviço pode ser proporcionado de acordo com um "protocolo de negocia- ção". Em uma modalidade particular, apesar do assunto reivindicado não estar limitado neste aspecto, um protocolo de negociação pode definir como as partes expressam um orçamento, a requisição de orçamento e/ou a men- sagem de aceitação. Em outra modalidade, as partes podem trocar mensa- gens de acordo com um protocolo de negociação até um estado e/ou evento predefinido particular definindo o fechamento. Aqui, tal fechamento pode de- finir os termos do acordo sob os quais um serviço é para ser proporcionado.

Deve ser entendido, entretanto, que estes são meramente exemplos de um protocolo de negociação e o assunto reivindicado não está limitado nestes aspectos.

Ao enviar um objeto digital a partir de um nó-fonte para um nó- destino através de uma rede de transmissão de dados, o equipamento que é possuído, alugado, controlado e/ou operado por um ou mais "intermediários" ou "partes intermediárias" pode enviar pelo menos uma parte do objeto digi- tal através de pelo menos uma parte da rede de transmissão de dados em direção ao nó-destino. Como ilustrado abaixo, o termo "intermediário" pode se referir a uma parte que pode enviar um objeto digital através de pelo me- nos uma parte da rede de transmissão de dados e/ou equipamento que é possuído, alugado, controlado e/ou operador pela parte para executar este serviço.

O equipamento que é possuído, alugado, controlado e/ou manti- do por um intermediário pode compreender equipamento que seja capaz de transmitir informação e/ou receber informação para/de uma rede de trans- missão dados. "Aqui, tal equipamento pode compreender uma ou mais "por- tas de comunicação" capazes de receber informação a partir de um nó-fonte e/ou transmitir informação para um nó-destino através de um ou mais meios de transmissão de dados formando ligações na rede de transmissão de da- dos. Tal porta de comunicação pode ser capaz de transmitir e/ou receber informações a partir de qualquer um dentre vários tipos de meios de trans- missão de dados tal como, por exemplo, cabeamento (por exemplo, óptico, coaxial, cabeamento de pares de fios trançados não protegidos, etc.) e/ou meio de transmissão sem fios (por exemplo, por ligações terrestres ou via satélite). Entretanto, estes são meramente exemplos de uma porta de comu- nicação que pode acoplar equipamento que é possuído, alugado, controlado e/ou operado por um intermediário para uma rede de transmissão de dados, e o assunto reivindicado não esta limitado nestes aspectos.

"Instruções" como referido neste documento refere-se a expres- sões que representam uma ou mais operações lógicas. Por exemplo, as ins- truções podem ser "legíveis por máquina" por serem interpretáveis por uma máquina para executar uma ou mais operações em relação a um ou mais objetos de dados. Entretanto, isto é meramente um exemplo de instruções e o assunto reivindicado não está limitado neste aspecto. Em outro exemplo, instruções, como referido neste documento, pode se relacionar com coman- dos codificados que são executáveis por um circuito de processamento pos- suindo um conjunto de comandos que inclui os comandos codificados. Tal instrução pode ser codificada na forma de uma linguagem de máquina en- tendida pelo circuito de processamento. Novamente, estes são meramente exemplos de uma instrução e o assunto reivindicado não está limitado neste aspecto.

"Meio de armazenamento" como referido neste documento refe- re-se a meio capaz de manter expressões que são percebíveis por uma ou mais máquinas. Por exemplo, um meio de armazenamento pode compreen- der um ou mais dispositivos de armazenamento para armazenar instruções legíveis por máquina e/ou informações. Tal dispositivo de armazenamento pode compreender qualquer um dentre vários tipos de meio incluindo, por exemplo, meio de armazenamento magnético, óptico ou semicondutor. En- tretanto, estes são meramente exemplos de um meio de armazenamento e o assunto reivindicado não está limitado a estes aspectos.

"Lógica" como referido neste documento refere-se a a estrutura para executar uma ou mais operações lógicas. Por exemplo, a lógica pode compreender conjunto de circuitos que proporcionam um ou mais sinais de saída baseado em um ou mais sinais de entrada. Tal conjunto de circuitos pode compreender uma máquina de estado finito que recebe uma entrada digital e proporciona uma saída digital, ou conjunto de circuitos que propor- cionam um ou mais sinais de saída analógicos em resposta a um ou mais sinais de entrada analógicos e/ou digitais. Tal conjunto de circuitos pode ser proporcionado em um circuito integrado de aplicação específica (ASIC) ou arranjo de portas programáveis em campo (FPGA). Além disso, a lógica po- de compreender instruções legíveis por máquina armazenadas em um meio de armazenamento em combinação com o conjunto de circuitos para execu- tar tais instruções legíveis por máquina. Entretanto, estes são meramente exemplos de estruturas que podem proporcionar lógica e o assunto reivindi- cado não está limitado a estes aspectos.

Um "agente" como referido neste documento refere-se a um processo que executa em um primeiro dispositivo e que é capaz de se co- municar com um segundo dispositivo através de uma rede de transmissão de dados. Em uma modalidade particular, por exemplo, um processo agente pode coletar informações associadas com o primeiro dispositivo e permitir a transmissão das informações coletadas para o segundo dispositivo. Em ou- tra modalidade, um agente pode receber sinais de controle a partir do se- gundo dispositivo para permitir o controle remoto de pelo menos um aspecto do primeiro dispositivo. Entretanto, estes são meramente exemplos de como um agente pode permitir a comunicação entre os dispositivos e o assunto reivindicado não está limitado a estes aspectos. Em outra modalidade, um agente pode executar em um processador sob o controle de instruções legí- veis por máquina armazenadas em um meio de armazenamento. Em outra modalidade, um agente pode ser executado em tipos de estrutura diferentes que proporcionam lógica. Entretanto, estes são meramente exemplos de um agente e o assunto reivindicado não está limitado a estes aspectos.

Uma "qualidade de serviço" ("QoS") como referido neste docu- mento refere-se a uma característica de um serviço de transmissão de da- dos para proporcionar dados para um recebedor dentro das restrições parti- culares. Em exemplos particulares, apesar do assunto reivindicado não estar limitada a este aspecto, a QoS pode se referir à distribuição de um serviço dentro de restrições esperadas de largura de banda, restrições de tempo e/ou restrições de erro. Uma qualidade de serviço pode se referir a uma ca- racterística de um protocolo do tipo protocolo de controle de transmis- são/protocolo Internet (TCP/IP), e/ou a um protocolo do tipo protocolo de datagrama de usuário/protocolo Internet (UDP/IP). Em uma ou mais modali- dades, uma qualidade de serviço pode se referir a um taxa limite de trans- missão de erro, por exemplo, onde um ou mais pacotes de dados podem não chegar, e/ou onde um ou mais pacotes que realmente chegam podem incluir um ou mais bits de informação corrompidos. Em uma ou mais modali- dades, uma qualidade de serviço pode se referir a onde nenhum erro e/ou nenhuma taxa de erro é aceitável, e/ou a um limite onde o número de erros e/ou a taxa de erro não pode exceder a um valor predeterminado, e/ou a uma faixa dentro da qual um número de erros e/ou uma taxa de erro pode ser aceitável, apesar do escopo do assunto reivindicado não estar limitado a estes aspectos. Em uma modalidade particular, por exemplo, uma QoS pode estar associada com a transmissão de um objeto digital a partir de um nó- fonte para um nó-destino. Aqui, por exemplo, a QoS pode ditar que todo ou uma parte do objeto digital chegue no nó-destino dentro de limites definidos de largura de banda, e/ou dentro de alguma restrição de tempo, e/ou com ou sem número de erros e/ou dentro de limites de taxa de erro. Em outra moda- lidade, a QoS pode definir, pelo menos em parte, uma taxa de dados eficaz na qual um objeto digital é para ser transmitido para o nó-destino. Entretan- to, isto é meramente um exemplo de como a QoS pode ser aplicada na transmissão de um objeto digital e o assunto reivindicado não está limitado a este aspecto.

A não ser que especificamente de outro modo dito, como apa- rente a partir da discussão seguinte, é apreciado que por todo este relatório descritivo, as discussões utilizando termos tais como "processamento", "computação", "cálculo", "seleção", "formando", "permitindo", "inibindo", "i- dentificando", "iniciando", "recebendo", "transmitindo", "determinando" e/ou assim por diante se referem às ações e/ou procedimentos que podem ser executados por uma plataforma de computação, tal como um computador ou um dispositivo de computação eletrônica similar, o qual manipula e/ou trans- forma os dados representados como quantidades físicas, eletrônicas e/ou magnéticas e/ou outras quantidades físicas dentro dos processadores, me- mórias, registros e/ou outros dispositivos de armazenamento, transmissão, recepção e/ou exibição da plataforma de computação. Adicionalmente, a não ser que especificamente dito de outro modo, o processo descrito neste do- cumento, com referência aos fluxogramas ou a outros contextos, também pode ser executado e/ou controlado, no todo, ou em parte, por tal plataforma de computação.

A figura 1 é um diagrama esquemático de uma rede de trans- missão de dados 25 de acordo com uma modalidade. Um nó-fonte 2 e nós- destino 18 até 24 podem acessar a rede de transmissão de dados 25 utili- zando qualquer uma dentre várias tecnologias de acesso à transmissão de dados tal como, por exemplo, rede comutada de telefonia pública (PSTN), linha digital do assinante (DSL), cabo coaxial/óptico ou acesso sem fios (por exemplo, utilizando ligações via satélite e/ou terrestres). Entretanto, estes são meramente exemplos de como um nó pode obter acesso a uma rede de transmissão de dados e o assunto reivindicado não está limitado a estes as- pectos. A rede de transmissão de dados 25 pode ser capaz de transmitir pa- cotes de dados entre os nós em uma topologia de rede de acordo com um Protocolo Internet (IP). Entretanto, isto é meramente um exemplo de um pro- tocolo de comunicação que pode ser utilizado na transmissão de todo ou de parte de um objeto digital a partir de um nó-fonte para um nó-destino e o as- sunto reivindicado não está limitado a este aspecto. Aqui, em uma modali- dade particular ilustrada na Figura 1, o nó-fonte 2 e os nós-destino 18 até 24 podem acessar a rede de dados 25 através de dos recursos de provedores de serviço Internet (ISPs) 10 e 16. Por exemplo, o nó-fonte 2 e/ou os nós- destino 18 até 24 podem compreender assinantes de ISPs correspondentes que permite acesso à rede de transmissão de dados 25 por uma taxa de as- sinatura. Entretanto, um ISP é meramente um exemplo de como um nó-fonte e/ou destino pode acessar uma rede de transmissão de dados e o assunto reivindicado não está limitado a este aspecto.

De acordo com uma modalidade, o nó-fonte 2 e/ou os nós- destino 18 até 24 podem compreender qualquer um dentre vários tipos de dispositivos que são capazes de transmitir e/ou receber objetos digitais. Em um exemplo particular, o nó-fonte e/ ou os nós-destino 18 até 24 podem compreender uma porta de comunicação (não apresentada) que é adaptada para transmitir dados e/ou receber dados a partir de um ISP através de um meio de transmissão de dados utilizando uma ou mais tecnologias de aces- so mencionadas acima. Em adição às portas de comunicação, o nó-fonte 2 e/ou os nós-destino 18 até 24 também podem compreender uma plataforma de computação empregando um processador, um ou mais dispositivos de memória e dispositivos apropriados de entrada/saída para comunicação en- tre os processos executando no processador e nas portas de comunicação. Aqui, tais processos executando em uma plataforma de computação podem ser controlados, pelo menos em parte, por instruções legíveis por máquina armazenadas em um ou mais dispositivos de memória da plataforma de computação. Em uma modalidade particular, uma plataforma de computação no nó-fonte 2 pode executar um ou mais processos para criar e/ou formatar um objeto digital para transmissão na rede de transmissão de dados 25. En- tretanto, isto é meramente um exemplo de como um nó-fonte 2 pode criar e/ou formatar um objeto digital para transmissão em uma rede de transmis- são de dados e o assunto reivindicado não está limitado a este aspecto. Em outra modalidade particular, uma plataforma de computação em um nó- destino pode executar um ou mais processos para utilizar um objeto digital recebido a partir da rede de transmissão de dados 25 através de uma porta de comunicação. Entretanto, isto é meramente um exemplo de como um nó- destino- pode processar um objeto digital recebido a partir de uma rede de transmissão de dados e o assunto reivindicado não está limitado a este as- pecto.

De acordo com uma modalidade, o equipamento que é possuí- do, alugado, controlado e/ou operado pelos intermediários 12 pode transmitir objetos digitais entre ISPs 10 e 16. As ligações acoplando o equipamento intermediário com o ISPs 10 e 16 pode compreender qualquer um dentre vários meios de transmissão de dados tal como, por exemplo, cabeamento (por exemplo, fibra óptica, coaxial e/ou cabeamento de pares trançados não protegidos) e/ou meio de transmissão sem fios (por exemplo, utilizando liga- ções baseadas em satélite ou terrestres). Entretanto, estes são meramente exemplos de meio de transmissão que pode ser utilizado para transmitir ob- jetos digitais em uma rede de transmissão de dados e o assunto reivindicado não está limitado a estes aspectos.

Como ilustrado na Figura 1, o ISP 10 pode transmitir um objeto digital para o ISP 16 em qualquer um dentre vários caminhos compreenden- do pelo menos um intermediário correspondente 12. Aqui, de acordo com uma modalidade particular, o ISP 10 pode transmitir um objeto digital para o ISP 16 através de qualquer dentre os vários intermediários 12a, 12b e/ou 12c. Como discutido abaixo, de acordo com uma modalidade particular, o nó-fonte 2 e/ou o ISP 10 pode selecionar um intermediário particular 12 para enviar o objeto digital para o ISP 16 baseado, pelo menos em parte, em um ou mais orçamentos recebidos a partir dos intermediários 12a, 12b e/ou 12c. Entretanto, isto é meramente um exemplo de como um intermediário pode ser selecionado para enviar um objeto digital e o assunto reivindicado não está limitado a este aspecto.

De acordo com uma modalidade, apesar do assunto reivindicado não estar limitado a este aspecto, os intermediários 12 podem direcionar objetos digitais entre os ISPs 10 e 16 em um ou mais pacotes de dados for- matados de acordo com um protocolo de rede particular tal como um Proto- colo Internet (IP). Tais pacotes de dados podem ser enviados em ligações de dados conectando os intermediários 12 e os ISPs de acordo com qual- quer um dentre vários protocolos de camada de ligação de dados tal como, por exemplo, Ethernet, Modo de Transferência Assíncrona (ATM), Retrans- rnissão de Quadros e/ou protocolos de ligação de dados de Rede Óptica Síncrona/Hierarquia Digital Síncrona (SONET/SDH). Na modalidade empre- gando as ligações de comunicação sem fios, os pacotes de dados podem ser enviados em tais ligações de comunicação sem fios de acordo com qualquer um dentre vários protocolos de ligação de dados sem fios via satéli- te e/ou terrestres, tal como, por exemplo padrões IEEE 802.11 e 802.16. En- tretanto, estes são meramente exemplos de protocolos de ligação de dados que podem ser utilizados para enviar pacotes de dados em uma rede de transmissão de dados e o assunto reivindicado não está limitado a este as- pecto. De acordo com uma modalidade, um intermediário 12 pode compreender um ou mais roteadores para enviar pacotes de dados se origi- nando no nó-fonte 2 para nós-destino. A figura 2 é um diagrama esquemáti- co de um roteador 28 que pode ser possuído, alugado e/ou operado em um intermediário para transmitir pelo menos uma parte de um objeto digital para um nó-destino de acordo com uma modalidade. O roteador 28 pode com- preender uma ou mais portas de comunicação de ingresso 24 para receber as comunicações de pacote de dados de acordo com um ou mais protocolos mencionados acima. Aqui, uma ou mais portas de comunicação de ingresso 24 podem ser capazes de receber todo ou parte de um objeto digital a partir do ISP 10 (e se originando no nó-fonte 2). O roteador 28 também pode com- preender uma ou mais portas de comunicação de egresso 26 para transmitir as comunicações de pacote de dados de acordo com um ou mais dos proto- colos mencionados acima. Aqui, uma ou mais das portas de comunicação de egresso 26 podem ser capazes de transmitir todo ou parte de um objeto digi- tal para o ISP 16 (para então ser enviado para um ou mais nós-destino).

De acordo com uma modalidade, o roteador 28 pode compreen- der lógica para determinar como enviar os pacotes recebidos nas portas de comunicação de ingresso 24 para as portas de comunicação de egresso 26 para enviar um pacote de dados recebido baseado, pelo menos em parte, na informação associada com o pacote de dados recebido, por exemplo, um endereço destino. Aqui, de acordo com uma modalidade particular, o rotea- dor 28 pode determinar uma porta de egresso 26 para enviar o pacote de dados recebido de acordo com uma ou mais tabelas de consulta associando o endereço IP destino com as portas de egresso 26. Entretanto, isto é me- ramente um exemplo de como um roteador pode determinar uma porta de egresso para enviar um pacote de dados e o assunto reivindicado não está limitado a este aspecto. Apesar da existência de um endereço destino válido associado com um pacote de dados recebido, de acordo com uma modali- dade, o roteador 28 também pode selecionar se envia ou não um pacote de dados recebido baseado, pelo menos em parte, na informação tal como des- tino e/ou fonte associada com o pacote de dados, ou em outra informação associada com o pacote de dados.

De acordo com uma modalidade, a lógica mencionada acima do roteador 28 para controlar o roteamento de pacotes de dados a partir de uma porta de comunicação de ingresso 24 para uma porta de comunicação de egresso 26 pode compreender uma ou mais plataformas de computação compreendendo um ou mais processadores e dispositivos de memória. Os dispositivos de memória podem compreender instruções legíveis por máqui- na para executar um ou mais processadores para controlar o direcionamento de pacotes de dados. Alternativamente, o roteador 28 pode compreender um ou mais dispositivos ASIC para controlar o roteamento, e/ou combinações de um ou mais dispositivos ASIC e uma ou mais plataformas de computação para controlar o roteamento. Entretanto, estes são meramente exemplos de lógica que pode ser empregada em um roteador para controlar o envio de pacotes de dados e o assunto reivindicado não está limitado a estes aspectos.

De acordo com uma modalidade, um intermediário 12 (Figura 1) pode empregar mais do que um roteador para enviar um objeto digital para um nó-destino. Um objeto digital recebido a partir do nó-fonte 2 em um pri- meiro roteador pode ser enviado para um segundo roteador onde tanto o primeiro como o segundo roteador é possuído, alugado, controlado e/ou o- perado pelo intermediário 12. Aqui, o primeiro roteador pode receber o obje- to de digital a partir do ISP 10 e enviar o objeto digital recebido para o se- gundo roteador diretamente para o segundo roteador ou via um ou mais ou- tros dispositivos de roteamento. O segundo roteador pode então enviar para o ISP 16 o objeto digital recebido a partir do primeiro roteador. Entretanto, isto é meramente um exemplo de como um intermediário pode empregar vários roteadores para enviar um objeto digital a partir de um nó-fonte para um nó-destino, e o assunto reivindicado não está limitado a este aspecto.

De acordo com uma modalidade, os intermediários 12 e/ou os ISPs 10 e 16 podem empregar comutação por rótulo com vários protocolos (MPLS) de acordo com a Arquitetura MPLS exposta na Força-Tarefa de En- genharia da Interne (IRTF), Grupo de Trabalho de Rede, RFC 3031, 2001. Aqui, o ISP 10 pode compreender um "roteador de borda" (LER) que é ca- paz de designar valores de rótulo para pacotes recebidos a partir do nó-fonte 2 para transmissão para um nó-destino. Um ou mais roteadores dos inter- mediários 12 podem compreender um "roteador de comutação por rótulo" (LSR) para tomar as decisões de envio para os pacotes de dados recebidos baseado, pelo menos em parte, nos valores de rótulo designados para os pacotes de dados recebidos. Em um salto de rede entre o ISP 10 e o ISP 16, um LSR associado com um intermediário 12 pode retirar um rótulo existente de um pacote de dados recebido e aplicar um novo rótulo indicando como o próximo LSR a jusante é para enviar o pacote de dados para um destino. Os LSRs acoplados para enviar um objeto digital a partir do ISP 10 para o ISP 16 podem então formar um Caminho de Comutação por Rótulo (LSP) deter- minado, pelo menos em parte, de acordo com os rótulos (por exemplo, sele- cionado a partir de uma hierarquia de rótulos tal como uma pilha de rótulos) designados para os pacotes de dados transportando um objeto digital no salto de rede entre o ISP 10 e o ISP 16. Entretanto, isto é meramente um exemplo de como um objeto digital pode ser transmitido entre os nós em uma rede de transmissão de dados utilizando a MPLS e o assunto reivindi- cado não está limitado a estes aspectos.

A figura 3 é um diagrama esquemático de uma rede de trans- missão de dados 100 para transmitir um objeto digital para dois ou mais nós- destino de acordo com uma modalidade. Um nó-fonte 102 pode transmitir um objeto digital para mais do que um nó-destino acoplado com um ou mais ISPs 116. Dois ou mais intermediários 112 podem então ser empregados para enviar o objeto digital para os dois ou mais destinos. De acordo com uma modalidade, um objeto digital formatado parâ transmissão para um nó- destino pode ser copiado no ISP 10 ou em um intermediário 112 para trans- missão para vários destinos.

De acordo com uma modalidade, um objeto digital pode ser segmentado e/ou dividido em subobjetos digitais menores para transmissão através de dois ou mais intermediários. Aqui, em uma modalidade particular, um subobjeto digital pode ficar na faixa de tamanho dentre sendo tão grande quanto o maior objeto digital, tão pequeno quanto um objeto nulo não con- tendo dados, ou de um tamanho intermediário contendo, por exemplo, paco- te, sub-pacote, agregação de pacotes e/ou uma agregação de bits formando o subobjeto digital. De acordo com uma modalidade, apesar do assunto rei- vindicado não estar limitado a este aspecto, os objetos sub-digitais formando um objeto digital podem ser independentemente transmitidos através de uma rede de transmissão de dados para um destino utilizando o mesmo caminho ou caminhos diferentes. Sujeito a qualquer requerimento QoS, por exemplo, os intermediários podem orçar para o serviço de enviar subobjetos digitais individuais de um objeto digital maior como descrito neste documento. Aqui, por exemplo, um objeto digital pode ser suficientemente grande de modo que pode ser desejável dividir o objeto digital em um ou mais subobjetos di- gitais, por exemplo, no nó-fonte e/ou em um ou mais dos nós intermediários, onde um ou mais dos subobjetos digitais podem ser proporcionados com seus próprios requerimentos individuais de roteamento, qualidade de servi- ço, caminhos de roteamento, e assim por diante, e onde os subobjetos digi- tais podem ser remontados em um ou mais dos nós intermediários e/ou em um ou mais dos nós-destino. Tal conceito de subobjeto digital em uma ou mais modalidades pode ser análogo à transferência de dados utilizando pa- cotes, onde os subobjetos digitais podem estar em um nível mais elevado de organização que um pacote, mas podem estar em um nível inferior de orga- nização do que um objeto digital maior. Por exemplo, um objeto multimídia pode ser dividido em um subobjeto digital de vídeo e em um subobjeto digital de áudio, e/ou um objeto multimídia pode ser dividido em subobjetos digitais correspondendo às cenas contidas no objeto multimídia, apesar do escopo do assunto reivindicado não estar limitado a este aspecto. Um exemplo de tal objeto digital que pode ser adequado para ser um objeto digital dividido pode ser onde o objeto digital é um filme. Em uma ou mais modalidades, uma transmissão de tal objeto pode incluir um sistema de transmissão com várias entradas, várias saídas (MIMO) e/ou um sistema de acesso múltiplo com divisão espacial, por exemplo, onde dois ou mais subobjetos podem ser transmitidos em paralelo em duas ou mais ligações. Em uma modalidade particular, uma rede que pode ser adequada para dividir um objeto digital em um ou mais subobjetos digitais pode compreender pelo menos uma parte da rede operando de acordo com um padrão do tipo 802.16 do Instituto de En- genheiros Elétricos e Eletrônicos (IEEE) tal como um padrão do tipo WiMax1 apesar do escopo do assunto reivindicado não estar limitado a este aspecto.

Como na rede de transmissão de dados 25 ilustrada acima, um intermediário 112 pode compreender um ou mais roteadores (tal como o ro- teador 28, por exemplo) para enviar pacotes de dados para um nó-destino. Além disso, a rede de transmissão de dados 100 pode empregar a MPLS e selecionar intermediários particulares para enviar um objeto digital para des- tinos.

Na modalidade particular apresentada na Figura 3, um único in- termediário 112b pode ser capaz de enviar um objeto digital a partir do ISP 110 para os nós-destino acoplados com qualquer um dos ISPs 116a, 116b e/ou 116c. Por outro lado, nem o intermediário 112a nem o intermediário 112c podem, por si próprio, ser capaz de enviar um objeto digital para os nós-destino acoplados com todòs os três ISPs 116a, 116b e 116c. Para en- viar o objeto digital para os nós-destino acoplados com todos os ISPs, o ISP 110 e/ou o nó-fonte 102 podem selecionar o intermediário 112b, ou os inter- 20 mediários 112a e 112c.

De acordo com modalidades das~redes de transmissão de dados apresentadas na Figura 1 e/ou na Figura 3, um intermediário pode incorrer em um custo para enviar um objeto digital a partir de dentro de pelo menos uma parte da rede de transmissão de dados. Para compensar tal custo, um intermediário pode receber compensação a partir de uma parte associada com um nó-fonte, ISP e/ou destino em troca por enviar um objeto digital a- través de uma parte da rede. De acordo com uma modalidade, um interme- diário pode proporcionar um orçamento especificando termos sob os quais o intermediário enviaria um objeto digital através de pelo menos uma parte de uma rede de transmissão de dados. Uma parte que é para compensar um intermediário pode selecionar dentre vários orçamentos para o negócio de enviar o objeto digital através de pelo menos uma parte da rede. Entretanto, isto é meramente uma modalidade ilustrativa e o assunto reivindicado não está limitado a estes aspectos.

De acordo com uma modalidade, qualquer nó, tal como os nós intermediários e/ou o ISP atuando em nome de outro nó tal como um nó- fonte, nós intermediários, ISP e/ou nó-destino 118, por exemplo, pode requi- sitar a transmissão de um objeto digital. Da mesma forma, um nó-fonte e/ou destino pode junto requisitar e/ou de outro modo concordar em transmitir um objeto digital, por exemplo, como resultado de uma comunicação ("handsha- ke") entre o nó-fonte e/ou o nó-destino, e/ou entre pelo menos um dentre o nó-fonte e/ou o nó-destino, nós intermediários, e/ou um ou mais nós inter- mediários ("proxy"). Em uma ou mais modalidades, uma comunicação pode se referir a uma autenticação do tipo protocolo CHAP ("Protocolo de Autenti- cação de Aperto de Mão de Desafio") entre um servidor da rede e um dispo- sitivo cliente, apesar do escopo do assunto reivindicado não estar limitado a este aspecto. Uma comunicação pode ocorrer via comunicação direta entre dois ou mais nós, e/ou alternativamente uma comunicação pode ocorrer via comunicação indireta entre dois ou mais nós, por exemplo, utilizando correio eletrônico ou outro protocolo adequado. Em uma ou mais modalidades, um servidor intermediário ("proxy") pode se referir a um servidor, nó, e/ou dispo- sitivo cliente que pode operar para proporcionar, implementar, processar e/ou interceptar requisições em nome de dado outro servidor, nó, e/ou dis- positivo cliente, e/ou para operar interposto entre um primeiro servidor, nó, e/ou dispositivo cliente e o segundo servidor, nó, e/ou outro dispositivo clien- te. Tal servidor intermediário pode operar para proporcionar, implementar, processar, e/ou interceptar uma requisição em nome de e/ou em vez de pelo menos um tal servidor, nó, e/ou dispositivo cliente, e/ou pode operar como um agente de pelo menos um dentre um servidor, nó, e/ou dispositivo clien- te, e em uma ou mais modalidades, pode aparecer para outros servidores, nós, e/ou dispositivos clientes em uma rede de transmissão de dados como se no entanto ele fosse de dato o servidor, nó, e/ou dispositivo cliente para o qual tal intermediário pode estar atuando como um agente do mesmo. Tal servidor e/ou agente intermediário pode ser implementado em qualquer um ou mais dentre um nó-fonte, ISP fonte, nós intermediários, ISP destino, e/ou nós-destino, e/ou em outros nós em uma rede de transmissão de dados. Em uma ou mais modalidades, tal servidor e/ou agente intermediário pode ser utilizado para implementar uma ou mais funções especializadas como parte do processo como um todo e/ou processos para transmitir um objeto digital via uma rede de transmissão de dados. Por exemplo, se um objeto digital fosse um objeto com tamanho grande que poderia ser dividido em um ou mais subobjetos digitais ou pacotes com tamanho menor para transmissão mais eficiente, um servidor intermediário ("proxy") dedicado a tal divisão de um objeto digital pode ser utilizado. Outras funções especializadas de um servidor e/ou agente intermediário podem existir, por exemplo, compactação, descompactação, recombinação, e assim por diante. Entretanto, estes são meramente exemplos de como um servidor e/ou agente intermediário pode operar em uma rede de transmissão de dados e o escopo do assunto reivin- dicado não está limitado a estes aspectos.

A figura 4 é um fluxograma ilustrando um processo 200 para ini- ciar a transmissão de um objeto digital a partir de um nó-fonte de acordo com modalidades das redes de transmissão de dados 25 e 100. Todo ou algumas partes do processo 200 podem ser executadas pela lógica em um nó-fonte. Em uma modalidade particular, como ilustrada abaixo, partes do processo 200 podem ser executadas em um servidor intermediário ("proxy") (por exemplo, em um ISP ou em outro nó não identificado em uma rede de transmissão de dados) que seja capaz de se comunicar com um nó-fonte e um ou mais intermediários. No bloco 202, um nó-fonte pode formar um obje- to digital para transmissão para um ou mais nós-destino. Em uma modalida- de particular, um operador de computador pode formar o objeto digital atra- vés de interações com uma interface gráfica com o usuário (GUI) de uma plataforma de computação associada com e/ou acoplada com o nó-fonte. Entretanto, isto é meramente um exemplo de como um objeto digital pode ser formado e o assunto reivindicado não está limitado a estes aspectos. Em uma modalidade particular, o objeto digital pode ser formatado em um ou mais pacotes de dados de acordo com um protocolo de rede tal como o pro- tocolo IP. Como tal, o um ou mais pacotes de dados pode compreender uma parte de cabeçalho com um endereço IP destino associado com um nó- destino. Se o objeto digital for para ser transmitido para mais do que um nó- destino, o bloco 202 pode formatar vários conjuntos de pacotes de dados para nós-destino correspondentes com os endereços IP destino correspon- dentes. De acordo com modalidades particulares* apesar do assunto reivin- dicado não estar limitado a estes aspectos, tais vários conjuntos de pacotes de dados podem ser copiados para transmissão para os vários destinos cor- respondentes em um nó-fonte, ISP e/ou intermediário. Entretanto, estes são meramente exemplos de onde as cópias de pacotes de dados de objeto digi- tal podem ser feitas para transmissão para vários destinos, e o assunto rei- vindicado não está limitado a este aspecto.

Um intermediário particular em uma rede de transmissão de da- dos pode ou não ser capaz de transmitir um objeto digital para um nó- destino. Na modalidade particular da rede de transmissão de dados 100 a- presentada na Figura 3, por exemplo, não existe ligação conectando o in- termediário 112a com o ISP 116c, e nenhuma ligação conectando o inter- mediário 112c com o ISP 116a. Por conseqüência, o intermediário 112a po- de ser julgado incapaz de enviar objetos digitais para os nós-destino 118c, 120c e/ou 122c. Da mesma forma, o intermediário 112c pode ser julgado incapaz de enviar objetos digitais para os nós-destino 118a, 120a e 122a. Em outras modalidades, um intermediário pode ou não ser capaz de enviar um objeto digital para um destino baseado, pelo menos em parte, em outros fatores independentes de se o intermediário está conectado com um nó- fonte e/ou destino por uma ligação. Aqui, por exemplo, tal nó intermediário pode ser julgado incapaz baseado, pelo menos em parte, em falhas conhe- cidas do equipamento, na inabilidade de enviar o objeto digital de acordo com uma QoS desejada, e assim por diante. Entretanto, estes são mera- mente exemplos de como e/ou porque um intermediário pode ser incapaz de enviar um objeto digital para um destino e o assunto reivindicado não está limitado a estes aspectos.

No bloco 204, o nó-fonte e/ou o servidor intermediário podem identificar intermediários que sejam capazes de enviar um objeto digital para um ou mais nós-destino. Em uma modalidade, um nó-fonte e/ou servidor intermediário pode identificar intermediários que sejam capazes de enviar um objeto digital baseado, pelo menos em parte, em informações em uma base de dados. Tal base de dados pode ser mantida em um nó-fonte e/ou servidor intermediário e pode identificar intermediários particulares que estão conectados com o nó-fonte e capazes de receber o objeto digital para envio. Tal base de dados também pode associar informação com intermediários tal como, por exemplo, capacidade de enviar objetos digitais enquanto ainda alcançando uma certa QoS1 condição de operação (por exemplo, funcionan- do, parado para manutenção, funcionando mal, etc.) e informação indicativa de destinos para os quais os intermediários podem enviar objetos digitais. Entretanto, isto é meramente um exemplo de informação que pode estar as- sociada com os intermediários em uma base de dados para o propósito de identificar intermediários que sejam capazes de enviar objetos digitais para um destino e o assunto reivindicado não está limitado a este aspecto.

No bloco 206, um nó-fonte e/ou servidor intermediário pode ini- ciar a transmissão de requisições de orçamento para um ou mais intermediá- rios, requisitando orçamentos para um serviço de envio de objeto digital para um ou mais nós-destino. Aqui, uma requisição pode ser transmitida através de um canal de gerenciamento dentro de banda de ligações que transportam pacotes de dados de objetos digitais transmitidos entre uma fonte e um in- termediário. Alternativamente, uma requisição de orçamento pode ser transmitida para o intermediário em uma ligação que é separada de uma ligação transportando objetos digitais. Um nó-fonte e/ou servidor intermediá- rio pode transmitir requisições de orçamento para intermediários de acordo com qualquer um dentre vários protocolos de comunicação. Em uma moda- lidade particular, por exemplo, um nó-fonte e/ou servidor intermediário pode transmitir a requisição de orçamento em um ou mais pacotes de dados utili- zando um protocolo de datagrama do usuário/Protocolo Internet (UDP/IP). Entretanto, estes são meramente exemplos de como um nó-fonte e/ou servi- dor intermediário pode transmitir uma requisição de orçamento para um ou mais intermediários è o assunto reivindicado não está limitado a estes as- pectos.

De acordo com uma modalidade, uma forma de transmissão di- gital (DTF) pode compreender metadados associados com um objeto digital que podem ser armazenados separadamente, representados e/ou transmiti- dos independentemente dò objeto digital associado. Em modalidades parti- culares, apesar do assunto reivindicado não estar limitado a este aspecto, os DTFs associados com objetos digitais podem ser transmitidos entre os nós em uma rede de transmissão de dados (por exemplo, nó-fonte, ISPs e/ou intermediários) utilizando os caminhos de dados utilizados para transmitir objetos digitais. Em modalidades alternativas, os DTFs associados com ob- jetos digitais podem ser transmitidos entre os nós em uma transmissão de dados utilizando os caminhos de dados que são distintos dos caminhos de dados utilizados para transmitir objetos digitais. Entretanto, estes são mera- mente exemplos de como os DTFs podem ser transmitidos entre os nós em uma rede de transmissão de dados e o assunto reivindicado não está limita- do a estes aspectos.

De acordo com uma modalidade particular, uma requisição de orçamento pode ser formatada como DTF que pode ser transmitido em uma ou mais mensagens de acordo com um protocolo de negociação. Aqui, um DTF pode compreender campos predefinidos que especificam termos de uma requisição de orçamento para o serviço de transmitir um objeto digital para um nó-destino. Tais campos predefinidos podem ser utilizados para proporcionar informação para uma parte que faz levantamento de preço tal como, por exemplo, tamanho do objeto digital a ser transmitido (por exem- plo, em bits, bytes, células, pacotes, etc.), endereço(s)-destino, QoS, formato de compactação, segurança, criptografia, número de conta de faturamento e/ou assim por diante. Alternativamente, um DTF pode compreender uma referência para um esquema de definição de campo predefinido e/ou para o próprio esquema, e/ou os valores de campo expressos em um formato, por exemplo, XML. Entretanto, estes são meramente exemplos de campos pre- definidos que podem ser utilizados no DTF para proporcionar uma requisição de orçamento e o assunto reivindicado não está limitado a estes aspectos.

Como salientado acima, um DTF pode facilitar um processo de levantamento de preço para um serviço de envio de um objeto digital associ- ado para um destino. Em adição ao enviar objetos digitais como conseqüên- cia do levantamento de preço, em modalidades particulares, apesar do as- sunto não estar limitado a este aspecto, uma rede de transmissão de dados pode permitir o envio de outro tráfego de dados que não exija aceitação de um orçamento como conseqüência de formação e/ou transmissão de um DTF. Aqui, por exemplo, as partes podem ter acordos existentes e/ou rotas para enviar tráfego que eliminam uma necessidade de levantamento de pre- ço. Entretanto, isto é meramente um exemplo de como uma rede de trans- missão de dados pode enviar tráfego de dados sem o uso de um DTF e o assunto reivindicado não está limitado a este aspecto.

Como discutido acima, um nó-fonte pode enviar um objeto digital para mais do que um nó-destino. Além disso, como salientado acima, certos intermediários podem não ser capaz de enviar um objeto digital para todos os nós-destino pretendidos. Por conseqüência, em uma modalidade particu- lar, diferentes mensagens de requisição de orçamento podem ser enviadas para diferentes intermediários baseado, pelo menos em parte, em habilida- des conhecidas de intermediários particulares em enviar o objeto digital para destinos particulares (por exemplo, como determinado no bloco 204). Refe- rindo-se ao exemplo da Figura 3, de acordo com uma modalidade particular, o nó-fonte 102 pode formatar um objeto digital para transmissão para nós- destino 118a, 118b e 118c. O intermediário 112a pode receber uma ou mais requisições de orçamento para envio do objeto digital para os nós-destino 118a e 118b, mas não para enviar o objeto digital para o nó-destino 118c. Da mesma forma, o intermediário 112c pode receber uma ou mais requisi- ções de orçamento para enviar o objeto digital para os nós-destino 118b e 118c, mas não para enviar o objeto destino para o nó-destino 118a.

Nas modalidades ilustradas acima, o bloco 204 pode identificar um ou mais intermediários que são capazes de enviar um objeto digital para um nó-destino. Entretanto, em modalidades alternativas, o bloco 206 pode enviar requisições de orçamento para qualquer nós intermediário identificá- vel, independente de se tais nós intermediários são determinados como ca- pazes dè proporcionar um serviço desejado. Isto permite aos intermediários determinar para eles próprios se eles são capazes de enviar o objeto digital para o destino sob os termos do orçamento. Por conseqüência, o uso do bloco 204 ao identificar intermediários capazes é meramente uma modalida- de opcional, e o assunto reivindicado não está limitado a estes aspectos.

Após um período de tempo seguindo à transmissão das requisi- ções de orçamento para intermediários no bloco 206, o nó-fonte e/ou o ser- vidor intermediário pode receber um ou mais orçamentos a partir de um ou mais intermediários expressando uma habilidade e/ou disposição em enviar um objeto digital para um ou mais destinos de acordo com os termos expos- tos em um ou mais orçamentos recebidos. Tais termos no orçamento podem incluir, por exemplo, preço, QoS, tempo esperado de distribuição e/ou latên- cia máxima. Entretanto, estes são meramente exemplos de termos que um intermediário pode proporcionar em um orçamento para a transmissão de um objeto digital para um ou mais destinos, e o assunto reivindicado não está limitado a este aspecto.

Ao receber um ou mais orçamentos a partir de um ou mais in- termediários, um nó-fonte e/ou servidor intermediário pode processar os or- çamentos recebidos no bloco 208. O blocos 208 pode selecionar um ou mais intermediários para enviar o objeto digital para um ou mais nós-destino ba- seado, pelo menos em parte, em um ou mais orçamentos recebidos. Em uma modalidade particular, para enviar um objeto digital para um nó-destino particular, o bloco 208 pode selecionar um intermediário especificando o preço mais baixo em seu orçamento para este serviço. Alternativamente, o bloco 208 pode selecionar um intermediário especificando um orçamento mais baixo para uma QoS mínima especificada associada com enviar o obje- to digital para o nó-destino. Em uma modalidade particular, apesar do assun- to reivindicado não estar limitado a este respeito, a aceitação e/ou a rejeição de um orçamento, e/ou o término de um processo de levantamento de preço, pode ser determinado, pelo menos em parte, em um protocolo de negocia- ção predeterminado. Aqui, por exemplo, tal protocolo de negociação pode determinar um formato para os orçamentos, mecanismos para rejeitar orça- mentos chegando posteriormente (por exemplo, após um período limite), rejeição de orçamentos devido a uma parte solicitando um orçamento ter relações preexistentes com outros intermediários para proporcionar um ser- viço de envio de um objeto digital, e/ou similares.

Um protocolo de negociação também pode definir vários tipos de mensagem incluindo, por exemplo, requisições de orçamento, orçamentos, reconhecimento de uma requisição de orçamento e/ou do orçamento, rejei- ção e/ou aceitação de um orçamento, difusão de resultados de uma requisi- ção de orçamento e de orçamentos subseqüentes, e/ou alterações para le- vantamentos de preços futuros para o serviço de envio de um objeto digital. Entretanto, estes são meramente exemplos de mensagens que podem ser definidas como parte de um protocolo de negociação e o assunto reivindica- do não está limitado a estes aspectos.

Ao selecionar um intermediário para enviar um objeto digital para um nós-destino, o nó-fonte e/ou servidor intermediários pode iniciar o inter- mediário selecionado para enviar pacotes de dados carregando o objeto digi- tal para um ou mais nós-destino. Em uma modalidade particular empregando o protocolo MPLS mencionado acima, por exemplo, o nó-fonte e/ou o servi- dor intermediário pode identificar um nó em uma rede de transmissão de dados (por exemplo, o nó-fonte ou ISP conectado com o nó-fonte) para atuar como um LER. Aqui, tal LER pode associar pacotes de dados carregando um objeto digital com um rótulo de comutador identificando o objeto digital e como o objeto digital é para ser processado por um LSR receptor. O LER pode então enviar os pacotes de dados carregando o objeto digital para uma porta de comunicação de ingresso do roteador atuando como um LSR e que é possuído, alugado, controlado e/ou operado pelo intermediário seleciona- do. Entretanto, isto é meramente um exemplo de como tal intermediário se- lecionado pode ser estabelecido para enviar pacotes de dados carregando um objeto digital para um nó-destino e o assunto reivindicado não está limi- tado a este aspecto. A figura 5 é um fluxográma ilustrando uma modalidade do pro- cesso 300 para atuar de acordo com a requisição de orçamento recebida em um intermediário de acordo com uma modalidade. A modalidade de proces- so 300 pode ser executada pela lógica associada com um intermediário tal como, por exemplo, um sistema de computador como ilustrado acima. Entre- tanto, isto é meramente um exemplo de lógica que é capaz dé executar um processo para atuar de acordo com uma requisição de orçamento e o assun- to reivindicado não está limitado a este aspecto. De acordo com uma moda- lidade, um intermediário pode receber uma mensagem compreendendo uma requisição de orçamento (por exemplo, na forma de um DTF) no bloco 302. Como descrito acima, uma requisição de orçamento pode ser transmitida a partir de um nó-fonte e/ou de um servidor intermediário de acordo com um protocolo de comunicação utilizando uma mensagem dentro de banda transmitida em ligações para transmitir objetos digitais. Como tal, um inter- mediário pode receber uma requisição de orçamento em uma porta de co- municação de ingresso de um roteador que é capaz de receber pacotes de dados carregando objetos digitais a partir de um nó-fonte. Alternativamente, um intermediário pode receber uma requisição de orçamento em uma porta de comunicação que está acoplada com uma ligação de uma rede diferente que é dedicada para transmitir e/ou receber mensagens compreendendo requisições de orçamento, orçamentos e/ou mensagens de gerenciamento. Entretanto, estes são meramente exemplos de como uma requisição de or- çamento pode ser recebida em um intermediário e o assunto reivindicado não está limitado a este aspecto,

O bloco 304 pode determinar os termos para um orçamento para um serviço de envio de um objeto digital para um nó-destino. Como ilustrado acima, tal orçamento pode especificar termos e/ou condições sob as quais um intermediário pode concordar com o negócio de envio de um objeto digi- tal para um nó-destino. O bloco 304 pode determinar estes termos e/ou con- dições baseado, pelo menos em parte, em custos capitais de equipamento (por exemplo, para roteadores e equipamento de suporte relacionado), cus- tos de operação (incluindo, por exemplo, manutenção dos bens, aluguel, energia, pessoal), capacidade atual e/ou prognosticada, utilização atual e/ou prognosticada de recursos, experiência anterior e/ou histórico, contratos preexistentes com outras partes, preferência de vendedor, comportamento antecipado de orçamento a partir dos intermediários competidores para a transmissão do objeto digital para o destino, demanda antecipada e/ou habi- lidade em proporcionar uma QoS particular para a transmissão do objeto digital. Entretanto, estes são meramente exemplos de informações que um intermediário pode utilizar ao determinar termos para um orçamento para a transmissão de um objeto digital para um nó-destino e o assunto reivindica- do não está limitado a este aspecto.

Seguindo à determinação dos termos de um orçamento no bloco 304, um intermediário pode transmitir o orçamento para um nó-fonte e/ou servidor intermediário no bloco 306. Tal orçamento pode ser transmitido para um nó-fonte e/ou servidor intermediário através de uma porta de comunica- ção que é capaz de receber objetos digitais a partir do nó-fonte e/ou transmi- tir objetos digitais para destinos na rede de transmissão de dados. Alternati- vamente, tal orçamento pode ser transmitido em uma mensagem fora de banda em uma ligação de dados diferente. Entretanto, estes são meramente exemplos de ligações que podem ser utilizadas para transmitir uma mensa- gem compreendendo um orçamento e o assunto reivindicado não está limi- tado a estes aspectos. Em outra modalidade, a mensagem compreendendo um orçamento pode ser transmitida de acordo com qualquer dentre vários protocolos tal como, por exemplo, UDP/IP e/ou um protocolo proprietário. Entretanto, este é meramente um exemplo de um protocolo de comunicação que pode ser utilizado para a transmissão de um orçamento para um nó- fonte e/ou servidor intermediário e o assunto reivindicado não está limitado e este aspecto.

Deve ser entendido que, de acordo com uma modalidade parti- cular, um intermediário recebendo uma requisição de orçamento no bloco 302 pode escolher não responder à requisição de orçamento por qualquer uma dentre várias razões tal como, por exemplo, uma inabilidade em enviar o objeto digital para um nó-destino especificado e/ou capacidade insuficiente para satisfazer a QoS do serviço requisitada, uma política para não fazer negócio com este solicitante particular ou classe de solicitantes e/ou assim por diante. Alternativamente, um intermediário pode transmitir uma mensa- gem para um nó-fonte e/ou servidor intermediário indicando que o intermedi- ário não irá fazer o orçamento para o negócio de enviar o objeto digital em questão. Em outra modalidade, um intermediário também pode transmitir uma razão para não participar no processo de levantamento de preço.

Seguindo à transmissão de um orçamento no bloco 306, o pro- cesso 300 pode aguardar por uma resposta a partir de um nó-fonte e/ou ser- vidor intermediário indicando que o orçamento transmitido foi aceito ou rejei- tado. Tal mensagem de aceitação a partir de um nó-fonte e/ou servidor in- termediário pode tomar a forma de uma mensagem transmitida dentro de banda junto com objetos digitais ou como uma mensagem fora de banda em uma rede separada. Em uma modalidade, por exemplo, o losango 308 pode determinar a aceitação de um orçamento quando da recepção de um ou mais pacotes de dados em uma porta de comunicação de ingresso carre- gando pelo menos uma parte do objeto digital e endereçado para o nó- destino, proporcionando uma mensagem de aceitação implícita. Em uma modalidade alternativa, o losango 308 pode determinar uma rejeição do or- çamento se nenhum pacote de dados carregando pelo menos uma parte do objeto digital for recebido em uma porta de comunicação de ingresso dentro de um período predeterminado seguindo à transmissão do orçamento no bloco 306. Em outra modalidade alternativa, o losango 308 pode determinar se o orçamento é aceito ou rejeitado baseado em uma mensagem de aceita- ção ou mensagem de rejeição explícita recebida a partir de uma ligação de dados dentro de banda e/ou fora de banda. Entretanto, estes são meramen- te exemplos de como um intermediário pode determinar a aceitação e/ou a rejeição de um orçamento para um serviço de envio de um objeto digital e o assunto reivindicado não está limitado as estes aspectos.

Em resposta a uma indicação de que um orçamento foi aceito, o losango 308 pode permitir o envio de um objeto digital para um nó-destino no bloco 310. De acordo com uma modalidade na qual um intermediário compreende um ou mais roteadores capazes de atuar como LSRs em uma rede MPLS, por exemplo, o bloco 310 pode permitir que um ou mais rotea- dores em um LSP enviem pacotes de dados para um ou mais nós-destino. Os pacotes de dados identificados como carregando o objeto digital baseado nos rótulos de comutador associados podem ser enviados através do LSP em direção a um ou mais nós-destino. De acordo com uma modalidade, o intermediário pode receber pacotes de dados carregando um objeto digital em uma porta de comunicação de ingresso de um roteador inicial. Os paco- tes de dados carregando um objeto digital ao longo de um LSP (ou possi- velmente vários LSPs para mais do que um nó-destino) podem percorrer um ou mais roteadores até serem transmitidos a partir de uma porta de egresso de um roteador final para o nó-destino. Em uma modalidade alternativa, um Protocolo de Dispositivo de Interconexão de Rede Interior (IGP) pode ser utilizado para rotear o tráfego. Entretanto, estes são meramente exemplos de como um intermediário pode permitir o envio de um objeto digital para um destino e o assunto reivindicado não está limitado a estes aspectos.

Em resposta a uma indicação de que um orçamento foi rejeitado, o losango 308 pode inibir o envio de um objeto digital para o nó-destino no bloco 312 se a proposta for rejeitada. Em uma modalidade particular, por exemplo, o bloco 312 pode inibir o envio de pacotes de dados recebidos em uma porta de ingresso de um roteador, por exemplo, por cancelar pacotes sendo recebidos em uma porta de ingresso de um roteador sem informar um remetente. Entretanto, isto é meramente um exemplo de como um interme- diário pode inibir o envio de um objeto digital e o assunto reivindicado não está limitado a este aspecto.

Como salientado acima, uma requisição de orçamento e/ou or- çamento relacionado pode se relacionar com enviar um objeto digital para vários nós-destino. Aqui, em uma modalidade particular, um nó-fonte e/ou servidor intermediário pode aceitar uma parte de um orçamento para envio de um objeto digital para um nó-destino e rejeitar uma parte do orçamento para enviar o objeto digital para um ou mais outros nós-destino. Por conse- qüência, nesta modalidade particular, o losango 308 pode permitir o envio de um objeto digital para alguns nós-destino (relacionando-se com uma parte aceita de um orçamento) e inibir o envio do objeto digital para outros nós- destino (relacionando-se com uma parte rejeitada do orçamento). Entretanto, isto é meramente um exemplo de como um intermediário pode processar uma aceitação parcial de um orçamento para um serviço de enviar um objeto digital e o assunto reivindicado não está limitado a estes aspectos.

A figura 6 é um diagrama esquemático de uma rede de trans- missão de dados 400 para transmitir um objeto digital a partir de um nó-fonte para um ou mais nós-destino através de dois ou mais intermediários. Um nó- fonte 402, acoplado com a rede de transmissão de. dados 400 através do ISP 410, pode desejar enviar um objeto digital para um nó-destino acoplado com o ISP 416. O ISP 410 pôde enviar um objeto digital para os intermediá- rios 412a, 412b e/ou 412c sem quaisquer saltos intervenientes da rede. En- tretanto, os intermediários 412a, 412b e/ou 412c podem não ser necessari- amente capazes de enviar um objeto digital para um nó-destino sem ajuda de um ou mais intermediários a jusante. Aqui, nenhum intermediário único 412a, 412b e/ou 412c pode necessariamente ser capaz de enviar um objeto digital para o ISP 416 sem enviar o objeto digital através de pelo menos um intermediário a jusante 413a, 413b, 413c, 413d, 413e, 413f e/ou 413g. Da mesma forma, nenhum intermediário único 413a, 413b, 413c, 413d, 413e, 413f e/ou 413g pode ser capaz de enviar o objeto digital para o ISP 416 sem direcionar o objeto digital através de um intermediário η 415a, 415b, e/ou 415c.

Em resposta a uma requisição por um orçamento para o serviço de enviar um objeto digital a partir do ISP 410 para um nó-destino 404, 406 e/ou 408, de acordo com uma modalidade particular, um intermediário 412a, 412b, e/ou 412c pode proporcionar um orçamento compreendendo termos que são baseados, pelo menos em parte, em um custo associado com o en- vio do objeto digital através de um dos intermediários a jusante 412a até 413g. Enquanto executando o processo 300 (Figura 5), de acordo com uma modalidade particular para responder à requisição por um orçamento, no bloco 304, um intermediários 412a, 412b e/ou 412c pode transmitir uma re- quisição de orçamento para um ou mais intermediários a jusante 413a até 413g. Ao receber orçamentos a partir de um ou mais intermediários a jusan- te, o intermediário 412a, 412b e/ou 412c pode determinar termos para um orçamento para a transmissão do objeto digital recebido a partir do ISP 410 baseado, pelo menos em parte, em termos a partir de um ou mais orçamen- tos recebidos a partir de um ou mais intermediários a jusante. O intermediá- rio 412a, 412b e/ou 412 pode então completar o processo 300 como ilustra- do acima. Ao determinar orçamentos em resposta às requisições de orça- mento a partir dos intermediários 412a, 412b e/ou 412c, os intermediários 413a até 413g podem de forma similar requisitar orçamentos e/ou receber orçamentos a partir dos intermediários a jusante 415a, 415b e/ou 415c como ilustrado acima.

A figura 7 é um fIuxograma ilustrando uma modalidade de pro- cesso 450 para atuar de acordo com uma requisição de orçamento recebida em um intermediário de acordo com uma modalidade. De acordo com a mo- dalidade particular, a modalidade de processo 450 pode ser executada por um ou mais intermediários 412 em resposta a uma requisição de orçamento a partir de um nó-fonte e/ou servidor intermediário. Em outra modalidade, a modalidade de processo 450 pode ser executada por um ou mais dos inter- mediários a jusante 413 em resposta a uma requisição de orçamento a partir de um intermediário 412. No bloco 452, um intermediário pode receber uma requisição de orçamento como ilustrado acima com referência ao bloco 302 da Figura 5. No caso de receber uma requisição de orçamento em um inter- mediário a jusante 413, entretanto, deve ser entendido que tal requisição de orçamento pode originar-se de um intermediário 412. O bloco 454 pode iden- tificar um ou mais intermediários a jusante capaz de transmitir o objeto digital para o nó-destino como ilustrado acima com referência ao bloco 204 do pro- cesso 200.

O bloco 456 pode formular e transmitir uma requisição de orça- mento a jusante para os intermediários a jusante identificados no bloco 454. Os termos expostos em tal requisição de orçamento podem ser baseados, pelo menos em parte, nos termos expostos em uma ou mais requisições de orçamento recebidas no bloco 452. Em uma modalidade particular, por e- xemplo, uma requisição de orçamento formulada no bloco 456 pode caracte- rizar um objeto digital, especificar um ou mais nós-destino e indicar como o objeto digital é para ser transmitido para um ou mais nós-destino como des- crito acima com referência ao bloco 206 na Figura 4. As requisições de or- çamento formuladas no bloco 456 podem então ser transmitidas para um ou mais intermediários a jusante como uma mensagem dentro de banda e/ou fora de banda como ilustrado acima com referência ao bloco 206 acima.

No bloco 458, um intermediário pode receber um ou mais orça- mentos em resposta às requisições de orçamento transmitidas no bloco 456. Tais orçamentos recebidos no bloco 458 podem expressar termos tal como estes expressos nos orçamentos recebidos no bloco 208 como ilustrado a- cima. Aqui, a modalidade de processamento 450 pode aguardar por respos- tas seguindo à transmissão das requisições de orçamento no bloco 456 du- rante um período de tempo predeterminado seguindo à transmissão de uma ou mais requisições de orçamento. Então, o bloco 460 pode determinar os termos para um ou mais orçamentos para responder à requisição de orça- mento recebida no bloco 452. Os termos expostos nestes orçamentos po- dem ser baseados, pelo menos em parte, nos termos expostos em um ou mais orçamentos recebidos no bloco 456. Aqui, por exemplo, o bloco 460 pode determinar um preço associado com um orçamento em resposta á re- quisição de orçamento recebida no bloco 452 baseada, pelo menos em par- te, em um custo associado com um ou mais dos orçamentos recebidos no bloco 458. Entretanto, estes são meramente exemplos de como os termos de um orçamento para um serviço de transmitir um objeto digital para um destino podem ser determinados e o assunto reivindicado não está limitado a estes aspectos.

A discussão acima ilustra um processo pelo qual intermediários podem fazer orçamento para o negócio de proporcionar um serviço de envio de objetos digitais para nós-destino. Em modalidades particulares, uma rede de transmissão de dados pode transportar objetos digitais em pacotes de dados através de ligações conectando um nó-fonte e/ou ISP com intermediá- rios, e conectar intermediários com nós-destino. Em modalidades adicionais, uma rede separada, à parte de uma rede de transmissão de dados utilizada para enviar objetos digitais, pode facilitar uma troça de mensagens de ge- renciamento tal como, por exemplo, requisições de orçamento, e suas con- dições. Isto pode permitir o emprego centralizado das atividades de levan- tamento de preço e de faturamento para os serviços de envio de objetos di- gitais através da rede de transmissão de dados.

A figura 8 é um diagrama esquemático de uma rede de trans- missão de dados 500 compreendendo uma primeira rede para transmitir um objeto digital a partir de um nó-fonte para um nó-destino, e uma segunda rede para facilitar o levantamento de preço entre os intermediários. Um nó- fonte 502 pode ser acoplado com a rede de transmissão de dados 500 por um ISP 510. O nó-fonte 502 pode transmitir um objeto digital para um ou mais nós-destino 518 através do ISP 510, dos intermediários 512 e/ou do ISP 516. Para o propósito de ilustração, os nós são conectados por ligações de dados da primeira rede representada com linhas contínuas e nós são co- nectados por ligações de dados da segunda rede representada por linhas tracejadas. De acordo com uma modalidade particular, as ligações de dados representadas por linhas contínuas são capazes de transmitir um objeto digi- tal para um destino através de uma parte correspondente da primeira rede.

Além disso, as ligações de dados representadas pelas linhas tracejadas po- dem ser capazes de transmitir mensagens de controle, tal como, por exem- plo, requisições de orçamento, orçamentos e mensagens de aceitação, entre um servidor 522 e outros nós na rede de transmissão de dados 500.

De acordo com uma modalidade, o nó-fonte 502 pode transmitir requisições de orçamento para os intermediários 512 para um serviço de envio de um objeto digital para um ou mais nós-destino 508 como discutido acima. Os intermediários 512 também podem responder a tais orçamentos para este serviço como discutido acima. Nesta modalidade particular, entre- tanto, o servidor 522 ode se comunicar com o nó-fonte 502, com o ISP 510 e/ou com os nós intermediários através de ligações de dados na segunda rede para, entre outras coisas, transmitir requisições de orçamento para e/ou receber orçamentos a partir dos intermediários 512.

De acordo com uma modalidade, uma modalidade de processo de agente 520 pode executar em um ou mais intermediários 512 para se comunicar com o servidor 522. Por exemplo, em uma modalidade particular, uma instância de modalidade de processo de agente 520 pode ser executa- da pela lógica tal como instruções legíveis por máquina capazes de executar em um sistema de computador operado por um ou mais intermediários 512. Além disso, os intermediários 512 podem compreender portas de comunica- ção fora de banda que são capazes de comunicação na segunda rede que são distintas das portas de comunicação utilizadas para enviar objetos digi- tais na primeira rede. Em uma modalidade particular, o processo de agente 520 pode se comunicar com o servidor 522 através de tais portas de comu- nicações fora de banda.

De acordo com uma modalidade, as ligações da segunda rede podem compreender qualquer um dentre vários tipos de meio de transmis- são tal como, por exemplo, qualquer cabeamento e/ou meios sem fios men- cionados acima. Novamente, entretanto, estes são meramente exemplos de meios de transmissão que podem ser utilizados para transmitir mensagens na segunda rede e o assunto reivindicado não está limitado a estes aspec- tos. De acordo com uma modalidade particular, as mensagens podem ser transmitidas em ligações da segunda rede utilizando qualquer um dentre os protocolos de camada de ligação de dados mencionados acima, e podem ser formatadas para transmissão na segunda rede de acordo com qualquer um dos protocolos de rede mencionados acima. Entretanto, novamente, es- tes são meramente exemplos de ligações de dados e/ou de protocolos de rede e o assunto reivindicado não está limitado a estes aspectos.

De acordo com uma modalidade, um processo para levantar preços para o serviço de enviar um objeto digital a partir do nó-fonte 502 pa- ra um ou mais nós-destino 518 pode ser governado, pelo menos em parte, pelo servidor 522 e/ou pela modalidade de processo de agente 520. A figura 9 é um fluxograma ilustrando um processo 600 para iniciar a transmissão de um objeto de dados para um ou mais nós-destino de acordo com uma moda- lidade da rede de transmissão de dados 500. Em uma modalidade particular, por exemplo, a modalidade de processo 600 pode ser executada pela lógica no nó-fonte 502 e/ou ISP 510. No bloco 602, um objeto digital pode ser for- mulado como ilustrado acima com referência ao bloco 202 da Figura 4. En- tretanto, em vez de enviar as requisições de orçamento diretamente para os intermediários, o processo 600 pode enviar uma requisição de orçamento para o servidor 522 (por exemplo, através da segunda rede). Como ilustrado abaixo com referência à Figura 10, o servidor 522 pode então facilitar um processo de levantamento de preço entre os intermediários 512 para o ser- viço de enviar o objeto digital para um nó-destino e selecionar um intermedi- ário para enviar o objeto digital. O bloco 606 pode receber informação (por exemplo, através da segunda rede) a partir do servidor 522, a qual permite o envio do objeto digital para o intermediário selecionado. Por exemplo, o blo- co 606 pode receber um endereço de rede e/ou algum outro identificador associado com um intermediários selecionado 512 a partir do qual o ISP 510 pode transmitir pacotes de dados transportando um objeto digital para o in- termediários 512 selecionado. O bloco 608 pode então iniciar a transmissão do objeto digital para um intermediário selecionado baseado, pelo menos em parte, nas instruções de envio recebidas no bloco 606.

A figura 10 é um fluxograma ilustrando uma modalidade de pro- cesso 700 facilitando o levantamento de preço para serviço de envio de um objeto digital para um ou mais nós-destino de acordo com uma modalidade particular de uma rede de transmissão de dados da Figura 8. O bloco 702 pode receber uma requisição de orçamento a partir do nó-fonte 502 e/ou do ISP 510 a partir da segunda rede (por exemplo, transmitida no bloco 604). O bloco 704 pode então difundir a requisição de orçamento para um ou mais intermediários 512 através da segunda rede. Ao receber a requisição de or- çamento a partir da segunda rede, uma instância de agente 520 executando em um intermediário associado pode processar a requisição de orçamento e proporcionar um orçamento como ilustrado acima com referência à Figura 5. Entretanto, nesta modalidade particular, a instância de agente 520 pode re- ceber requisições de orçamento e transmitir orçamentos de/para o servidor 522 através da segunda rede.

Em uma modalidade, a modalidade de processo 700 pode inici- almente identificar os intermediários 512 que podem ser capazes de enviar um objeto digital para o destino como ilustrado acima com referência ao blo- co 204 (Figura 4) e limitar a transmissão de requisições de orçamento no bloco 704 para tais intermediários capazes 512. Alternativamente, a modali- dade de processo 700 pode meramente contar com as respostas às requisi- ções de orçamento e/ou com as ausências de resposta para determinar as capacidades dos intermediários 512 como ilustrado acima.

Ao receber os orçamentos a partir das instâncias de agente 520, a modalidade de processo 700 pode selecionar um ou mais intermediários 512 para enviar um objeto digital para um ou mais destinos, baseado, pelo menos em parte, nos termos estabelecidos nos orçamentos recebidos como ilustrado acima com referência ao bloco 208 (Figura 4). O bloco 708 pode então transmitir informação a ser utilizada no envio do objeto digital (por e- xemplo, endereço(s) de rede do intermediário(s) selecionado) através da segunda rede para o nó-fonte 502 e/ou o ISP 510 baseado, pelo menos em parte, em um ou mais intermediários selecionados.

De acordo com uma modalidade, o servidor 522 e/ou a modali- dade de processo de agente 520 pode manter informação de faturamento para os nós-fonte clientes e/ou ISPs. Por exemplo, o servidor 522 pode man- ter uma conta de despesas possuídas pelos intermediários para enviar obje- tos digitais que foram acumuladas como resultado do processo de levanta- mento de preço descrito acima e em outros contextos. Em uma modalidade particular, o bloco 710 pode atualizar a conta do nó-fonte 502 e/ou do ISP 510 de acordo com os termos de um orçamento proporcionado pelo inter- mediário 512 selecionado para enviar o objeto digital para o nó-destino. Por exemplo, o servidor 522 pode associar despesas com um número de conta proporcionado em um campo de um DTF como parte de uma requisição de orçamento recebida no bloco 702. Entretanto, isto é meramente um exemplo de manter a/ ou atualizar uma conta para despesas acumuladas para o en- vio de objetos digitais e o assunto reivindicado não está limitado a estes as- pectos.

Em outra modalidade particular, o servidor 522 pode coordenar o faturamento periódico de despesas acumuladas para os nós que utilizaram os serviços dos intermediários ao enviar objetos na rede de transmissão de dados. O servidor 522 pode também facilitar as despesas e/ou os pagamen- tos de conexão para intermediários tendo executado os serviços de envio de objetos digitais. Em uma modalidade, o servidor 522 pode manter contas de crédito para as partes (por exemplo, nós-fonte e/ou ISPs) que podem em- pregar os serviços dos intermediários ao enviar objetos digitais. Aqui, o ser- vidor 522 pode ordenar pagamento para intermediários para serviços execu- tados pelas partes a partir das contas de crédito das partes. Entretanto, es- tes são meramente exemplos de como o servidor 522 pode coordenar o fatu- ramento periódico para serviços executados pelos intermediários e o assun- to reivindicado não está limitado a estes aspectos.

Como ilustrado na Figura 3 acima, um nó-fonte pode enviar um objeto digital para vários nós-destino através de vários caminhos. Um primei- ro intermediário pode ser selecionado para enviar o objeto digital para um ou mais nós-destino através de um primeiro caminho e um segundo intermediá- rio pode ser selecionado para transmitir o objeto digital para um ou mais ou- tros nós-destino através de um segundo caminho. Deve ser aparente que as modalidades das Figuras 8 até 10 podem facilitar o levantamento de preços entre os intermediários para o serviço de envio de objeto digital em vários caminhos para vários destinos. Aqui, o servidor 522 pode proporcionar in- formação para o envio de objeto digital no bloco 708 para dois ou mais in- termediários correspondendo aos vários caminhos.

As figuras 6 e 7 acima ilustram um método e/ou sistema para a transmissão de um objeto digital para um nó-destino pelo envio do objeto digital através de dois ou mais intermediários. Aqui, de acordo com uma mo- dalidade particular, a segunda rede pode acoplar o servidor 522 com um nó- fonte e /; ou ISP, bem como com intermediários capazes de receber um ob- jeto digital a partir do ISP. Em resposta às requisições de orçamento a partir do servidor 522, as instâncias de agente 520 (executando nos intermediários acoplados com a segunda rede) podem obter orçamentos a partir de um ou mais intermediários a jusante (não apresentados). As instâncias de agente 520 podem então determinar os termos para os orçamentos para o serviço de envio de objeto digital para o nó-destino como ilustrado acima na modali- dade de processo 450 e transmitir os orçamentos para o servidor 522 atra- vés da segunda rede. Quando da aceitação de um ou mais Orçamentos, o servidor 522 pode transmitir uma ou mais mensagens de aceitação para uma ou mais instâncias de agente 520 através da segunda rede. Alternati- vamente, como ilustrado acima, uma aceitação pode ser implícita quando da recepção de um ou mais pacotes de dados em um intermediário transpor- tando todo ou partes do objeto digital. Quando da indicação de tal aceitação (explícita e/ou implícita), uma instância de agente 520 pode aceitar um ou mais dos ditos orçamentos recebidos a partir de um ou mais intermediários a jusante como ilustrado acima.

Enquanto foram ilustradas e descritas o que atualmente são consideradas como modalidades ilustrativas, será entendido pelos versados na técnica que várias outras modificações podem ser feitas, e equivalentes podem ser adotados, sem se afastar do assunto reivindicado. Adicionalmen- te, várias modificações podem ser feitas para adaptar uma situação particu- lar às instruções do assunto reivindicado sem se afastar do conceito central descrito neste documento. Portanto, é pretendido que o assunto reivindicãdo não seja limitado às modalidades particulares descritas, mas que o assunto reivindicado também possa incluir todas as modalidades situadas dentro do escopo do assunto reivindicado, e de equivalentes do mesmo.

Claims

1. Método, compreendendo: transmitir uma requisição de orçamento para um ou mais inter- mediários para transmissão de um objeto digital para um nó-destino em uma rede de transmissão de dados; e receber um orçamento a partir de pelo menos um dos ditos in- termediários, em resposta à dita requisição de orçamento, expressando um ou mais termos para a transmissão do objeto digital para o dito nó-destino.

2. Método, de acordo com a reivindicação 1, onde um ou mais intermediários são capazes de enviar pelo menos uma parte do objeto digital para o nó-destino em pelo menos uma parte de um caminho correspondente na rede de transmissão de dados acoplando um nó-fonte com o dito nó- destino.

3. Método, de acordo com a reivindicação 1, onde a requisição de orçamento adicionalmente compreende termos indicativos de uma quali- dade de serviço a ser associada com a transmissão do objeto digital.

4. Método, de acordo com a reivindicação 1, onde o objeto digital é formado para transmissão para vários nós-destino, e onde a requisição de orçamento adicionalmente compreende termos indicativos de transmissão do objeto digital para um ou mais dos ditos nós-destino.

5. Método, de acordo com a reivindicação 1, adicionalmente compreendendo: selecionar pelo menos um dos ditos intermediários para enviar o objeto digital para o destino baseado, pelo menos em parte, nos termos ex- pressos nos ditos orçamentos recebidos; e iniciar o envio do dito objeto digital para o dito pelo menos um intermediário.

6. Método, de acordo com a reivindicação 5, adicionalmente compreendendo transmitir uma mensagem de aceitação para o dito pelo menos um selecionado dos ditos intermediários antes do dito início do envio do dito objeto digital.

7. Método, de acordo com a reivindicação 5, onde o dito início do envido do dito objeto digital adicionalmente compreende: formatar o dito objeto digital em um ou mais pacotes de dados; associar um rótulo de comutador com o dito um ou mais pacotes de dados; e endereçar os ditos pacotes de dados para um roteador de comu- tação por rótulo.

8. Método, de acordo com a reivindicação 1, onde os ditos or- çamentos compreendem termos expressando informação de custo e/ou de faturamento.

9. Método, compreendendo; receber uma requisição de orçamento identificando um objeto digital e um nó-destino em uma rede de transmissão de dados; e transmitir um orçamento em resposta à dita requisição de orça- mento.

10. Método, de acordo com a reivindicação 9, adicionalmente compreendendo: determinar um custo associado com o envio do objeto digital pa- ra o dito nó-destino; e formar o dito orçamento para incluir termos compreendendo in- formação de preço, pelo menos uma parte da dita informação de preço sen- do derivada, pelo menos em parte, em relação ao dito custo.

11. Método, de acordo com a reivindicação 9, e adicionalmente compreendendo permitir o envio do dito objeto digital em resposta a deter- minar uma aceitação do dito orçamento.

12. Método, de acordo com a reivindicação 11, e adicionalmente compreendendo: receber um ou mais pacotes de dados transportando pelo menos uma parte do dito objeto digital; associar um rótulo de comutador com o dito um ou mais pacotes de dados; e enviar os ditos um ou mais pacotes de dados para um roteador de comutação por rótulo.

13. Aparelho, compreendendo: dispositivo para transmitir uma requisição de orçamento para um ou mais intermediários para transmissão de um objeto digital para um nó- destino em uma rede de transmissão de dados; e dispositivo para receber um orçamento a partir de pelo menos um dos ditos intermediários, em resposta à dita requisição de orçamento, expressando um ou mais termos para a transmissão do objeto digital para o dito nó-destino.

14. Aparelho, de acordo com a reivindicação 13, onde um ou mais intermediários são capazes de enviar pelo menos uma parte do objeto digital para o nó-destino em pelo menos uma parte de um caminho corres- pondente na rede de transmissão de dados acoplando um nó-fonte com o dito nó-destino.

15. Aparelho, de acordo com a reivindicação 13, onde a requisi- ção de orçamento adicionalmente compreende termos indicativos de uma qualidade de serviço a ser associada com a transmissão do objeto digital.

16. Aparelho, de acordo com a reivindicação 13, onde o objeto digital é formado para transmissão para vários nós-destino, e onde a requisi- ção de orçamento adicionalmente compreende termos indicativos de trans- missão do objeto digital para um ou mais dos ditos nós-destino.

17. Aparelho, de acordo com a reivindicação 13, adicionalmente compreendendo: dispositivo para selecionar pelo menos um dos ditos intermediá- rios para enviar o objeto digital para o destino baseado, pelo menos em par- te, nos termos expressos nos ditos orçamentos recebidos; e dispositivo para iniciar o envio do dito objeto digital para o dito pelo menos um intermediário selecionado.

18. Aparelho, de acordo com a reivindicação 17, adicionalmente compreendendo transmitir uma mensagem de aceitação para o dito pelo menos um selecionado dos ditos intermediários antes do dito início do envio do dito objeto digital.

19. Aparelho, de acordo com a reivindicação 17, onde o dito iní- cio do envido do dito objeto digital adicionalmente compreende: dispositivo para formatar o dito objeto digital em um ou mais pa- cotes de dados; dispositivo para associar um rótulo de comutador com o dito um ou mais pacotes de dados; e dispositivo para endereçar os ditos pacotes de dados com um roteador de comutação por rótulo.

20. Aparelho, de acordo com a reivindicação 13, onde os ditos orçamentos compreendem termos expressando informação de custo e/ou de faturamento.

21. Aparelho, compreendendo: dispositivo para receber uma requisição de orçamento identifi- cando um objeto digital e um nó-destino em uma rede de transmissão de dados; e dispositivo para transmitir um orçamento em resposta à dita re- quisição de orçamento.

22. Aparelho, de acordo com a reivindicação 21, adicionalmente compreendendo: dispositivo para determinar um custo associado com o envio do objeto digital para o dito nó-destino; e dispositivo para formar o dito orçamento para incluir termos compreendendo informação de preço, pelo menos uma parte da dita infor- mação de preço sendo derivada, pelo menos em parte, em relação ao dito custo.

23. Aparelho, de acordo com a reivindicação 21, e adicionalmen- te compreendendo o dispositivo para permitir o envio do dito objeto digital em resposta a determinar uma aceitação do dito orçamento.

24. Aparelho, de acordo com a reivindicação 23, e adicionalmen- te compreendendo: dispositivo para receber um ou mais pacotes de dados transpor- tando pelo menos uma parte do dito objeto digital; dispositivo para associar um rótulo de comutador com o dito um ou mais pacotes de dados; e dispositivo para enviar os ditos um ou mais pacotes de dados para um roteador de comutação por rótulo

25. Aparelho compreendendo uma plataforma de computação, a plataforma de computação sendo adaptada para: transmitir uma requisição de orçamento para um ou mais inter- mediários para transmissão de um objeto digital para um nó-destino em uma rede de transmissão de dados; e receber um orçamento a partir de pelo menos um dos ditos in- termediários, em resposta à dita requisição de orçamento, expressando um ou mais termos para a transmissão do objeto digital para o dito nó-destino.

26. Aparelho, de acordo com a reivindicação 25, onde um ou mais intermediários são capazes de enviar pelo menos uma parte do objeto digital para o nó-destino em pelo menos uma parte de um caminho corres- pondente na rede de transmissão de dados acoplando um nó-fonte com o dito nó-destino.

27. Aparelho, de acordo com a reivindicação 25, onde a requisi- ção de orçamento adicionalmente compreende termos indicativos de uma qualidade de serviço a ser associada com a transmissão do objeto digital.

28. Aparelho, de acordo com a reivindicação 25, onde o objeto digital é formado para transmissão para vários nós-destino, e onde a requisi- ção de orçamento adicionalmente compreende termos indicativos de trans- missão do objeto digital para um ou mais dos ditos nós-destino.

29. Aparelho, de acordo com a reivindicação 25, onde a dita pla- taforma de computação é adicionalmente adaptada para: selecionar pelo menos um dos ditos intermediários para enviar o objeto digital para o destino baseado, pelo menos em parte, nos termos ex- pressos nos ditos orçamentos recebidos; e iniciar o envio do dito objeto digital para o dito pelo menos um intermediário.

30. Aparelho, de acordo com a reivindicação 29, onde a dita pla- taforma de computação é adicionalmente adaptada para transmitir uma mensagem de aceitação para o dito pelo menos um selecionado dos ditos intermediários antes do dito início do envio do dito objeto digital·

31. Aparelho, de acordo com a reivindicação 29, onde a dita pla- taforma de computação é adicionalmente adaptada para: formatar o dito objeto digital em um ou mais pacotes de dados; associar um rótulo de comutador com o dito um ou mais pacotes e dados; e endereçar os ditos pacotes de dados para um roteador de comu- tação por rótulo.

32. Aparelho, de acordo com a reivindicação 25, onde os ditos orçamentos compreendem termos expressando informação de custo e/ou de faturamento.

33. Aparelho compreendendo uma plataforma de computação, a plataforma de computação sendo adaptada para: receber uma requisição de orçamento identificando um objeto digital e um nó-destino em uma rede de transmissão de dados; e transmitir um orçamento em resposta à dita requisição de orça- mento.

34. Aparelho, de acordo com a reivindicação 33, onde a dita pla- taforma de computação é adicionalmente adaptada para: determinar um custo associado com o envio do objeto digital pa- ra o dito nó-destino; e formar o dito orçamento para incluir termos compreendendo in- formação de preço, pelo menos uma parte da dita informação de preço sen- do derivada, pelo menos em parte, em relação ao dito custo.

35. Aparelho, de acordo com a reivindicação 33, onde a dita pla- taforma de computação é adicionalmente adaptada para permitir o envio do dito objeto digital em resposta a determinar uma aceitação do dito orçamen- to.

36. Aparelho, de acordo com a reivindicação 35, onde a dita pla- taforma de computação é adicionalmente adaptada para receber um ou mais pacotes de dados transportando pelo menos uma parte do dito objeto digital; associar um rótulo de comutador com o dito um ou mais pacotes de dados; e enviar os ditos um ou mais pacotes de dados para um roteador de comutação por rótulo.

37. Artigo, compreendendo: um meio de armazenamento compreendendo instruções legíveis por máquina armazenadas no mesmo para: iniciar a transmissão de uma requisição de orçamento para um ou mais intermediários para transmissão de um objeto digital para um nó- destino em uma rede de transmissão de dados; e receber um orçamento a partir de pelo menos um dos ditos in- termediários, em resposta à dita requisição de orçamento, expressando um ou mais termos para a transmissão do objeto digital para o dito nó-destino.

38. Artigo, de acordo com a reivindicação 37, onde um ou mais intermediários são capazes de enviar pelo menos uma parte do objeto digital para o nó-destino em pelo menos uma parte de um caminho correspondente na rede de transmissão de dados acoplando um nó-fonte com o dito nó- destino.

39. Artigo, de acordo com a reivindicação 37, onde a requisição de orçamento adicionalmente compreende termos indicativos de uma quali- dade de serviço a ser associada com a transmissão do objeto digital.

40. Artigo, de acordo com a reivindicação 37, onde o objeto digi- tal é formado para transmissão para vários nós-destino, e onde a requisição de orçamento adicionalmente compreende termos indicativos de transmis- são do objeto digital para um ou mais dos ditos nós-destino.

41. Artigo, de acordo com a reivindicação 37, onde o dito meio de armazenamento adicionalmente compreende instruções legíveis por má- quina armazenadas no mesmo para: selecionar pelo menos um dos ditos intermediários para enviar o objeto digital para o destino baseado, pelo menos em parte, nos termos ex- pressos nos ditos orçamentos recebidos; e iniciar o envio do dito objeto digital para o dito pelo menos um intermediário.

42. Artigo, de acordo com a reivindicação 41, onde o dito meio de armazenamento adicionalmente compreende instruções legíveis por má- quina armazenadas no mesmo para iniciar a transmissão de uma mensagem de aceitação para o dito pelo menos um selecionado dos ditos intermediários antes do dito início do envio do dito objeto digital.

43. Artigo, de acordo com a reivindicação 41, onde o dito meio de armazenamento adicionalmente compreende instruções legíveis por má- quina armazenadas no mesmo para: formatar o dito objeto digital em um ou mais pacotes de dados; associar um rótulo de comutador com o dito um ou mais pacotes de dados; e endereçar os ditos pacotes de dados para um roteador de comu- tação por rótulo.

44. Artigo, de acordo com a reivindicação 37, onde os ditos or- çamentos compreendem termos expressando informação de custo e/ou de faturamento.

45. Artigo, compreendendo: um meio de armazenamento compreendendo instruções legíveis por máquina armazenadas no mesmo para: receber uma requisição de orçamento identificando um objeto digital e um nó-destino em uma rede de transmissão de dados; e iniciar a transmissão de um orçamento em resposta à dita requi- sição de orçamento.

46. Artigo, de acordo com a reivindicação 45, onde o dito meio de armazenamento adicionalmente compreende instruções legíveis por má- quina armazenadas no mesmo para: determinar um custo associado com o envio do objeto digital pa- ra o dito nó-destino; e formar o dito orçamento para incluir termos compreendendo in- formação de preço, pelo menos uma parte da dita informação de preço sen- do derivada, pelo menos em parte, em relação ao dito custo.

47. Artigo, de acordo com a reivindicação 45, onde o dito meio de armazenamento adicionalmente compreende instruções legíveis por má- quina armazenadas no mesmo para permitir o envio do dito objeto digital em resposta a determinar uma aceitação do dito orçamento.

48. Artigo, de acordo com a reivindicação 47, onde o dito meio de armazenamento adicionalmente compreende instruções legíveis por má- quina armazenadas no mesmo para: receber um ou mais pacotes de dados transportando pelo menos uma parte do dito objeto digital; associar um rótulo de comutador com o dito um ou mais pacotes de dados; e iniciar o envio dos ditos um ou mais pacotes de dados para um roteador de comutação por rótulo.