CN101300562A - 关于服务汇聚架构使用的方法和装置 - Google Patents

Abstract

服务汇聚架构(103)在操作中被设置在多个独立的接入网络、控制网络和服务网络(104)与汇聚应用层(100)之间。然后，使用(202)这个服务汇聚架构接收服务请求，处理服务请求，提供对应的响应，并公布该响应，以便促成服务请求。处理服务请求可以包括：处理关于用于支持该服务请求的资源的服务请求、对应该服务请求的用户会话状态、和对应该服务请求的用户偏好。提供响应可以包括：提供包含处理后的服务请求和对服务请求的汇聚响应中的至少一个的响应。

Description

关于服务汇聚架构使用的方法和装置

技术领域

本发明通常涉及服务汇聚架构，更特别地，本发明涉及服务汇聚架构关于服务请求的使用。

发明背景

本领域已知各种类型的网络。作为说明性的例子，这些网络包括接入网络、控制网络和服务网络(本领域的普通技术人员会认识到，任何给定网络都可以充当这些网络类型中的一个或多个网络，使得给定网络可以包括例如接入和控制网络)。在某些情况下，集成的有限方面可能跨越两个或更多的这种网络来应用。但是，较典型地，这种网络在较多或较少的程度上彼此独立地操作。(正如本文中的使用，“独立”可以涉及技术独立性(在两个网络的操作彼此不兼容的情况下)、接入独立性(在两个网络由于缺失例如在它们之间的便利连接，而不能够彼此接入的情况下)、和/或操作独立性(在采用整体或部分地排除两个网络之间透明交互的方式而分离地管理两个网络的情况下)。)

因此，典型的现代技术用户会发现在他们日复一日的生活中，他们自身被大量不同的服务和/或终端用户设备所环绕，在许多情况下，这些不同的服务和/或终端设备是以完全相互独立的方式操作。当然，在终端用户设备为终端用户实现完全不同的服务时，从现有技术的角度来看，这种差别目前只产生很少关注。例如，在注意到无线电话提供双向语音电话服务而电视提供电视广播的接收时，目前只存在很少的关注；也就是，在从现有技术的角度来观察时，在这种网络之间集成的缺失并不必然会视为存在问题。

当考虑到在某些情况下，一些现有的网络集成并没有引起由这种集成所表现的更多潜在的积极影响(aggressive leveraging)时，这种关注缺失的程度就变得特别明显。例如，有线电视(cable)服务提供商目前通常通过综合网络来提供电话服务和电视接收服务。然而，在很大程度上，在许多情况下这种集成更多地是涉及传输模式，而不是涉及通过综合网络来提供服务集成。

这些情况的出现，大部分的原因是由于不同问题；目前代表现有技术的很多数量和类型的应用的存在。应用包括媒介，通过该媒介为给定的终端用户(或者其它网络元件或节点)最终实现各种服务和动作。换言之，网络提供传输通道，基于服务的应用将通过该传输通道到达给定的终端用户。例如，电话应用是允许电话服务通过给定网络到达给定的终端用户的应用。

给定应用通常需要相当多的原有智能(native intelligence)和纵向认识(vertical awareness)，以便成功地在给定网络中工作或者与给定网络合作。当然，这种情况反映了简单的事实，即大多数网络都设法相互独立，从而很大程度上阻止了任何想要跨越多重网络扩展给定应用的延伸范围的意图。存在着给定应用在多重网络上操作的情况，但是再一次地，这些情况通常表现为需要应用设计者或网络设计者进行相当大的努力，以便适应这种操作性能。这种高度定制的解决方案尽管在特定情况下是有用的，但是这些解决方案对于驱动更多的可能性意识方面的作用很小。

一种提议解决这种关注问题的解决方案包括，在一方面的多个独立的接入网络、控制网络、和服务网络之间与另一方面的汇聚应用层之间设置一种业务汇聚架构。(例如，参见在2004年11月22日提交的、申请号为60/630,106的标题为METHOD TO FACILITATE ASERVICE CONVERGENCE FABRIC(用于促成服务汇聚架构的方法)的在先提交的临时专利申请，在此结合其全部内容以供参考。)经过适当地配置和部署，这种服务汇聚架构能有效充当关于多个接入网络和控制网络的应用服务器，并能充当关于多个服务网络的控制服务器或应用网关。从不同方面来观察，为了保持遗留网络的操作能力，该服务汇聚架构优选地采用与接入或控制网络的行为一致的方式与服务网络进行交互，同时还采用与服务网络的行为一致的方式与接入或控制网络进行交互。这种服务汇聚架构通常具有对下述信息的访问权，这些信息是关于下述各项中的至少一个：终端用户信息、服务信息、网络信息、设备信息、资源信息、应用信息、和/或边缘网络关信息。

这种信息访问权允许和促成服务汇聚架构对关于多个网络中的至少一个实体的上下文信息的获取，并允许和促成对其它信息(特别地包括触发信息)的获取，这些其它信息是与这些网络中的至少一个网络相关联的至少第一实体相对应。然后，关于上下文信息，在服务汇聚架构中处理后者信息，以便形成处理后信息，然后，处理后信息被分发给与多个网络中的一个或多个网络相关联的至少一个实体。

这种配置允许使用服务汇聚架构来实现服务汇合。关于汇聚应用层的给定应用，可以至少部分地采用自动和透明的方式，通过服务汇聚架构实现这种汇合，以便通过从多个候选网络中进行动态的选择和使用，可以使给定应用得到促成。这又允许关于网络资源的影响程度(a degree of leveraging)达到以前不可能达到的程度。由于给定应用变得能够通过多个另外的独立网络来实现给定服务的传递，因此终端用户体验就变得更为透明和直观。

采用这种配置，通过使用网络附属设备的不同端点和点，并牵涉不同的应用服务器以及在不同的管理域下操作(其中“管理域”将被理解为是指联网计算机的组，其以每个某些方式关连，诸如通过一个或多个共同通信地址，并且通常在特定所有者或管理者的支持下操作)，给定的终端用户就可以牵涉到跨越多个接入网络的多种活动和/或通信会话中。然而，同时，各种支持的接入网络、应用服务器、和/或端点可以基本上彼此独立地运行。由于终端用户的汇聚的(converged)服务是另外跨越独立的管理域进行调节，因此这又可能阻止跟踪、协调、和/或管理终端用户的汇聚的服务。

附图简述

通过提供的下文详细叙述内容中所描述的关于服务汇聚架构的使用的方法和装置，特别是在结合附图研究下文的详细叙述内容时，就能够至少部分满足上述需要，其中，

图1包括根据本发明的各种实施例配置的示意图；

图2包括根据本发明的各种实施例配置的流程图；

图3包括根据本发明的各种实施例配置的框图。

熟练的技术人员将意识到，附图中的元件是出于简明和清晰的目的进行描述，它们并不必要按照规格进行绘制。例如，附图中某些元件的尺寸和/或相对位置可能相对于其它元件被夸大，这有助于更好地理解本发明的各种实施例。而且，为了避免对本发明这些各种实施例的理解产生过多干扰，通常并没有描绘出通用和非常了解的元件，这些元件在商业上可实行的实施例中是有用或必要的。还将进一步意识到，某些动作和/或步骤可能按照发生的特定顺序进行描述或叙述；然而本领域的普通技术人员将认识到，这种关于顺序的特性实际上并不是必需的。我们还将认识到，除非本文已经另外公开了特定的含义，否则在本文中使用的术语和表达都具有普通含义，这些普通含义是符合在查询和研究它们相应的各自领域中的这些术语和表达含义。

具体实施方式

总地来说，这些各种实施例提供了在多个网络与汇聚应用层之间的服务汇聚架构，该多个网络包括独立的接入网络、控制网络、和服务网络中的任何网络。然后，使用这种服务汇聚架构接收服务请求(即，查找提供的一个或多个标识的或隐含的服务的特定或隐含(implied)请求，这些服务是诸如与连接性相关的服务、应用或应用支持服务，等等)、处理服务请求、提供相应的响应、并公布该响应，以便促成该服务请求。在具有不同域的多网络、多应用、多设备系统中，将系统作为一个整体来考虑时，所接收的服务请求可能是不完全/不充分地表达的。例如，该服务请求对于特定的应用服务网络来说可能是原有的(native)并且在其形成中只考虑了该网络。处理服务请求可以包括：处理关于下述方面的服务请求：即，支持该服务请求的资源、对应于该服务请求的用户会话状态、和对应于该服务请求的用户偏好。提供响应可以包括提供包含下述各项中至少一个的响应：即，处理后的服务请求和对该服务请求的汇聚的响应。汇聚的响应是对于至少部分包含跨越多个接入网络、服务网络、设备和/或应用执行处理的请求的响应，以便形成更多为全局认识(globally-aware)的响应。同样地，处理后的服务请求是至少部分包含跨越多个接入网络、服务网络、设备和/或应用执行处理的请求，以便形成对于组成网络和/或设备更适合的请求。

通过一种方案，服务汇聚架构可以包括由服务请求接收机、服务请求路由器、和多个服务请求处理子元件所组成的元件。例子包括资源评估器、用户会话状态评估器、和用户偏好评估器，该资源评估器用于评估与支持该服务请求相对应的资源可用性，该用户会话状态评估器用于评估与支持该服务请求相对应的用户会话状态，该用户偏好评估器用于评估与支持该服务请求相对应的用户偏好。通过一种方案，服务管理网络元件可以接收合成信息，这些合成信息是关于资源可用性、用户会话状态、和用户偏好，以便处理该服务请求，并提供合成可公布的处理后的服务请求。服务请求公布器可以接收这种可公布的处理后的服务请求，并将它进行公布，从而促成支持服务请求。

通过一种方案，这种处理后的服务请求可以是修订的服务请求，该修订的服务请求被发送给服务器或网络元件，接着由服务器或网络元件履行该请求。处理后的服务请求还可以采取对请求实体的响应的形式，将它定向到合适的服务器，以便履行服务。而且，如果期望，可以由服务请求产生一个以上的处理输出。这种情况的一个例子是将应用行为拆分(split)到分离的应用服务器上的情况(例如，用户可以请求将由一个应用服务器拥有的单个视频/音频会话(可能是由第三方提供商拥有的无线局域网的因特网协议语音/视频呼叫，该呼叫通过住宅因特网协议网关被传送到单个呈现(rendering)设备)拆分为两个分离的应用，一种应用用于使用住宅电话来支持音频部分，该电话的公共交换电话网络线路是由本地公共交换电话网络的运营商提供服务，而原始会话的视频部分接着被流式传输到由有线电视运营商所服务的住宅电视)。实际上，如果期望，服务请求处理子元件可以确定将处理后的请求公布给服务器，以便提交所使用的资源，并还向请求者公布响应，将该请求者定向到该资源。

这种配置(例如，不同于基于单个呼叫服务器或网关的结构)可以胜过多个、完全不同的呼叫服务器和/或应用服务器。从终端用户和(一个或多个)汇聚的应用的角度来看，这又能使多种类型的呼叫服务器进行有效地无缝连接，从而提供汇聚。可以在很少或没有关于整体能力、等待时间、和/或实施成本的折衷的不合理预期的情况下，可以实现合成全局同步的服务行为。

在全面观察和研究下文的详细叙述之后，这些和其它益处就变得更清楚。现在参考附图，特别是参考图1，本领域的普通技术人员现在将意识到，包括汇聚应用层100的任何数量的应用(诸如是例如，第一应用101至第N应用102)可以通过合适的对应应用编程接口(未显示)与服务汇聚架构103相接。类似地，服务汇聚架构103通常将包括多个网络接口(未显示)，其中每个这种网络接口通常实现与一个(或者在不是通常的情况下，一个以上)对应网络的兼容交互，该对应网络是诸如第一网络105至第M网络106中的任何一个网络，这些网络包括可供选择的独立接入网络、控制网络、和/或服务网络104。(为了与每个网络提供商域中的资源进行交互，服务汇聚架构103可以例如依赖于接入网络的特定协议，诸如会话启动协议或OSA/Parlay。例如，在因特网协议多媒体子系统(IMS)的使用的情况下，服务汇聚架构103可以依赖于因特网协议多媒体子系统的服务控制(ISC)接口，该接口是基于会话启动协议。)

正如本领域的人员所认识的，服务汇聚架构103自身可以包括具有引擎的层，用于允许服务汇聚架构103获得信息，并使用该信息实现对指向用户终端的内容的处理，和/或另外通过在给定情况下可用于这种服务的各种网络来实现和选择这种内容的路由。总的来说，这种服务汇聚架构103将包括多个服务汇聚处理功能和多个服务汇聚支持功能(未显示)。

更特别地，服务汇聚架构自身可以包括下列功能部分中的一些或全部功能：

汇聚协调功能：这种功能优选为提供下列至少一个的汇聚：用户标识、设备、接入和服务所有权、会话控制、和资源能力。该汇聚协调功能包括逻辑实体，该逻辑实体除了别的特征之外还执行上下文和其它信息的处理，以便实现服务汇合。它从服务提供商和运营商的数据库，被手动地录入的简档信息、和/或从对应的网络、边缘和/或终端用户支持功能中获得输入。然后，使用协议或者使用目前可能存在的其它机制或者可能以后开发的其它机制，经由应用编程接口或经由来自其它网络实体的消息，通过各种应用来访问这个信息，该协议是诸如会话启动协议、超文本传输协议、可扩展标记语言。基于来自应用的请求，该汇聚协调功能还执行诸如资源分配和/或解除分配(de-allocation)、会话启动、修改、和/或终止的功能。这可以牵涉与核心网络、接入网络、边缘网络、或终端用户设备中的支持功能的交互，或者包括通过合适的遗留技术特定协议(或多个协议)与遗留接口的交互。这些功能可以直接通过汇聚协调功能设备或平台来执行，或者可以间接地通过重定向功能来执行。该汇聚协调功能还可以响应由网络支持功能、边缘支持功能、或客户端支持功能中的一个或多个功能的请求来执行动作。

网络支持功能：这种功能与会话控制网络相接，并可以与边缘基础设施设备和/或客户端设备相接。它还与汇聚协调功能相接。它向协调功能提供会话、接入、和权利信息。这些信息中的某些信息对于边缘或终端用户设备可能不是可用的。网络支持功能还可以响应该汇聚协调功能的命令来执行动作。

边缘支持功能：这种功能与接入网络和客户端设备相接。它可以在终端用户的管理控制下驻留在设备中。它还与汇聚协调功能相接。它向协调功能提供关于自身以及与它对端(subtend)的设备的会话、资源、和标识信息。边缘支持功能还可以响应汇聚协调功能的命令来执行动作。

客户端支持功能：这种功能与驻留在客户端设备中的应用和资源相接。这些资源可以包括网络接入、控制资源、格式变换或内容译码、诸如人接口(输入或输出)能力的媒体资源、或者其它资源。该客户端支持功能向汇聚协调功能提供关于自身的这个信息。客户端支持功能还可以响应汇聚协调功能的命令来执行动作。

本领域的普通技术人员将注意和意识到，应用和应用服务器接收来自汇聚协调功能的信息，并且还可以通过应用编程接口或标准化协议将信息提供给汇聚协调功能。采用这种方式，本领域的普通技术人员将认识和意识到，单独的应用可以通过服务汇聚架构与其它的应用汇合在一起。

采用这种配置和部署，服务汇聚架构103可以接收从汇聚应用层100中的应用到最终的终端用户107信息消费者的内容，和/或将能力从汇聚应用层100中的应用传递给最终的终端用户107的信息消费者。在初始传递应用服务和/或在这种传递的过程中，可以发生这种活动。服务汇聚架构103可以采用可能最适合当前的环境，并另外考虑与特定终端用户107或设定最相关的上下文的方式，来实现向给定终端用户107的应用能力的传递。

通过一种方案，可以存在汇聚协调功能和支持功能的多种外部特性，以便提供服务汇聚架构的功能。如果期望，汇聚协调功能可以与支持功能共址，从而使用一个设备执行两个架构部件的功能。

因此，可以看出，服务汇聚架构103提供汇聚的服务功能，该汇聚的服务功能可以使应用开发商建立在多种接入网络上透明操作的服务。为了实现这种服务，这种功能优选地支持与汇聚的应用通用的特征。这包括：跟踪用户标识、状态和简档；设备标识、状态和简档；会话状态；和跨越多个网络的位置(仅举几个例子)。在最低程度上，通过使用简单的应用编程接口，优选地揭示(expose)收集关于用户和他们的会话、资源和接入的信息，该应用编程接口可以由汇聚的服务开发商使用。这种更为丰富的汇聚功能将帮助解决冲突的资源请求，基于简档和状态信息对服务进行优先排序，免除应用的一些协调负担，并允许遗留应用迁移到其它接入网络和设备。

特别地，可以看出，这种服务汇聚架构能够增进和/或促成：

-与形成(虚拟的)汇聚网络一部分的全部网络中的呼叫控制功能和服务资源交互；

-基于每个用户的方式，来管理与多种应用通用的标识、会话、状态和偏好；

-提供用于应用开发商的开放接口，以便实现服务逻辑；

-使用网络原有协议，与每个网络中的终端用户设备和其它实体进行通信。

这些功能的组合产生了跨越网络和设备的无缝的、以用户为中心的服务迁移的框架。例如，这可以包括和允许具有至少部分地依赖于多个核心网络的协同操作和交互工作的汇聚的服务，其中至少一些核心网络彼此之间具有不同的域。这种服务汇聚架构103有效地给应用提供了一种协调标识、会话、服务、以及网络和设备资源的手段。正如单词“架构”所隐含的意思，在多个启用的平台上，这种汇聚的服务支持可以是集中式的和/或分布式的。

现在参考图2，并且假定提供201这样一种服务汇聚架构，该服务汇聚架构位于一方面的多个独立接入网络、控制网络和服务网络与另一方面的汇聚应用层之间，使用202该服务汇聚架构促成和完成一系列相关的任务，来提供当前揭示的处理过程200。这一系列步骤通常是在接收到服务请求时开始。这个服务请求可以包括例如开始新服务的请求、为现有的服务添加新资源的请求、将状态改变为与现有服务对应的请求、将给定服务从一个网络迁移到其它网络(或者从一个终端用户设备迁移到其它终端用户设备)的请求，等等。

这种服务请求可以从该服务汇聚领域自身外部的服务终端用户中接收。然而，通过另一种方案，这种服务请求也可以从该服务汇聚架构外部的应用或网络部件中接收。并且，通过再一种方案，这种服务请求可以从该服务汇聚架构自身的内部接收(例如，这种服务请求可以来源于包含该服务汇聚架构一部分的服务管理元件，这将在下面进行更详细的叙述)。

然后，这个处理过程200提供对接收的服务请求的处理，该服务请求是关于用于支持服务请求的资源、对应用户请求的用户会话状态、和对应服务请求的用户偏好。本领域的普通技术人员将意识到，对应用户请求或其它实体请求的用户会话状态，可以涉及除该状态所对应的服务会话之外的服务会话。例如，用户会话状态可以涉及被“摘机”并且在电话呼叫中被连接到其它点的用户。服务请求可以涉及一些其它服务，诸如对用户的位置导航“按压”广告。该服务请求不是必然地被耦合到电话呼叫会话，而是所关注的“用户正忙于电话呼叫”的用户会话状态。因此，在这种方面和实例中，用户会话状态被认为是对应于用户请求。通过一种方案，这种处理可以包括将至少部分的服务请求路由到资源处理器、会话状态处理器、和偏好处理器中的每一个处理器(其中这些处理器可以共享集成平台，或者可以包含分立的实体)。

处理关于用于支持服务请求的资源的服务请求，可以包括访问数据库，该数据库是诸如包含下述各项中至少一个的信息：有关用于支持服务请求的至少潜在可用资源的信息、有关用于支持服务请求的至少潜在可用资源当前可用性的信息、和/或有关对应于可能与支持服务请求相关的至少潜在可用资源的现有鉴权的信息。本领域的普通技术人员将意识和认识到，本文使用的“资源”是关于任何承载机制(诸如承载信道或其它支持功能、(一个或多个)可分配的扩频码、(一个或多个)时隙、服务质量的级别，仅举几个例子)或者其它支持功能(诸如特定的编码平台或方案、加密，等等)。本领域的普通技术人员也可以将“资源”理解为是关于任何应用呈现资产(renderingasset)，该资产可以用于或者所需用于建立、保持、和/或终止给定服务(包括但并不局限于服务鉴权、网络鉴权、接入网络能力(诸如带宽或(一个或多个)服务和它们的特性(诸如服务质量、支持或需要的协议(诸如MPEG-4、因特网协议语音协议、所谓的简易老式电话服务(POTS)、等等)))，用户可用的可寻址设备等等)。

处理关于对应服务请求的用户会话状态的服务请求，可以包括使用关于终端用户的、与服务请求有关的基本上当前会话状态的信息。这种信息可以包括例如，关于特定的终端用户是否具有当前活动会话的信息，和/或关于代表特定终端用户的当前活动的应用的信息。这种信息可以例如通过会话监视器进行收集，该会话监视器跟踪用户会话的当前状态。这种信息有效提供对下述内容的了解：给定终端用户是否当前正忙、给定应用是否当前正忙、或者给定终端用户是否处当前只有特定类型的服务(或应用)可以被接受的状态，等等。

处理关于对应服务请求的用户偏好的服务请求，可以包括使用关于预先建立规则和/或动态建立规则中的至少一个规则的信息，该预先建立规则是关于如何代表给定的服务受益者来促成服务，该动态建立规则是关于如何代表给定的服务受益者来促成服务。(本领域的普通技术人员将认识和意识到，本文使用的“服务受益者”可以指整体或部分地接收益处的任何终端用户、应用、或者基本上上任何服务请求源或其它实体，这些益处是源于实现特定服务请求。)

更特别地，这种用户偏好可以至少部分通过下述各项中的至少一个来建立：启动服务请求的实体(诸如平台或功能)、可以被用来促成服务请求的资源、可以参与服务请求的实体、服务请求的受益者、将被用来促成服务请求的应用等等。这些偏好可以是例如关于有关在何种触发环境下和在何种用户(或应用、网络、或设备)状态条件下等，将发生何种特定动作的规则或优先级。总的来说，这些偏好支配如何将特定服务提供给给定的终端用户。

在某些情况下，这种处理有效充当过滤活动。也就是，根据上面提到的每个着眼点来考虑信息请求(或者它的至少一部分)，从而显现出关于何种资源可用来促成请求服务、一个或多个必需或可选的元件的当前操作状态是否与一个或多个服务传递选项相兼容等等的合成情形(picture)。

根据这种显现的信息，这个处理过程200接着提供对服务请求的响应；也就是，通过一种方案，将这种服务请求响应至少部分形成为关于如上面叙述已经被预先显现的资源、用户会话状态、和相关用户偏好的信息的函数。通过一种方案，服务管理网络元件可以形成这个服务请求响应的一部分或全部。这种服务管理网络元件可以、或可以不必、与一个或多个特定域进行特定关联(通过例如所有权和/或操作管理)。通过一种方案，这种服务管理网络元件也可以具有对其它信息源的访问权(诸如但并不局限于，在服务汇聚架构外部的域元件，包括具有一部分其它、不同的服务汇聚架构的域元件)。

这种服务请求响应可以包括例如处理后的服务请求、对服务请求的汇聚响应、或者可能与给定的操作上下文相关的其它响应。在很多情况下，提供的服务请求响应将包括用于处理服务请求的特定方式，这种方式是从处置服务请求的多种潜在方式中选择的。

通过一种方案，服务管理网络元件使用前面提到的信息来通知这种选择处理，该信息是关于资源、用户会话状态、和相关的用户偏好。但是，也可以使用其它标准。例如，如果期望，对用于处置服务请求的特定方式的选择，可以是部分基于跨越多个域实现特定性能级别的努力(例如，通过尝试跨越多个候选可用网络或设备来优化性能条件)。性能条件可以包括诸如下述内容的因素：连接比特速率、等待时间、抖动、用户或服务提供商的成本、网络负载、电源/电池寿命、用户偏好、设备输入/输出特性、或者在给定的应用设定中可能相关的其它条件。

这个处理过程200还提供对选定响应的公布，从而促成服务请求。公布通常将是期望的，这至少部分是由于服务管理网络元件自身缺失必要的手段和/或授权，用于实现对服务请求的特定选定响应。这种公布可以例如被定向到一个或多个服务请求的请求者、一个或多个资源拥有者、和/或在服务汇聚架构中的其它服务管理网络元件，注意到还有少数潜在的相关公布目标。

采用这种配置，服务汇聚架构就能够调节跨越多个网络的服务请求。更特别地，通过使用跨越一个以上管理域(例如，对应接入网络、服务网络、终端用户平台、等等)的条件集合，可以支持(或者甚至优化)对给定服务请求的支持。为了说明的目的，服务请求可以通过对应呼叫的第一域进行提交，以传送给特定的终端用户。按照这些教导，服务汇聚架构可以知道这个终端用户正忙于在第二域，并且当处理该服务请求以便制定合适的服务请求响应时可以并入该知识。

本领域的普通技术人员将意识到，使用广泛变化的可用和/或容易配置的平台中的任何平台，就能很容易实现上述的处理过程，这些平台部分或全部地包括本领域已知的可编程平台、或者可能期望用于实现某些应用的专用用途平台。现在参考图3，现在将提供对这种网络元件的说明性方案。

正如上面所提到的内容，这个网络元件300是预期用于服务汇聚架构中，该服务汇聚架构被部署在多个独立的接入网络、控制网络和服务网络与汇聚应用层之间。在这个说明性的实施例中，网络元件300包括服务请求接收机301，该接收机301被配置和设置为接收来自服务终端用户、应用、和服务管理网络实体中的任何一个的服务请求，该服务管理网络实体包含服务汇聚架构的一部分，这已经在上面进行了主要叙述。

服务请求接收机301在操作中耦合到服务请求路由器302。后者接收来自服务请求接收机301的服务请求，并路由该服务请求(或它的相关部分)，以便执行上述的处理/过滤(这里是使用资源评估器303、用户会话状态评估器304、和用户偏好评估器305进行说明)。资源评估器303用来评估与支持该服务请求对应的资源可用性。用户会话状态评估器304用来评估与支持该服务请求对应的用户会话状态。用户偏好评估器305用来评估与支持该服务请求对应的用户偏好。

通过一种可选的方案，然后，将这些评估器的输出耦合到服务管理网络元件306，该服务管理网络元件306被配置和设置为使用合成信息来处理服务请求，从而提供可公布的处理后的服务请求响应。通过其它可选的方案，服务管理网络元件306在自身中并入一个或多个评估器。

在这个说明性的实施例中，服务请求公布器307接收到可公布的服务请求响应，并用来公布该响应，从而促成支持由服务请求接收机301原先接收的对应服务请求。

本领域的普通技术人员将认识到和理解，这种网络元件300可以由多个物理上分立的元件组成，这在图3所显示的插图中已经间接表明。但是，也可以将这个图示看作是包含逻辑视图，在这种情况下通过共享的平台就可以启用和实现一个或多个这些元件。我们也将认识到，这种共享的平台可以整体或至少部分地包括本领域已知的可编程平台。

这些教导提供了很多不同的优点。例如，这些教导提供了交互管理域的协调，而不需要在不同、独立的管理域之间进行并行紧密的耦合。这些教导也是高度可变的，以便适应一个网络或应用的更新，但不需要适应其它网络或应用的更新。通常，这些教导帮助为汇聚的服务提供相对适度的迁移路径，而不需要不适当的预先投资和基础设施。

本领域的普通技术人员将认识到，在不脱离本发明的精神和范围的情况下，可以对上述的实施例进行各种修改、改变和组合，这种修改、改变和组合应当被认为是涵盖在本发明原理的范围内。例如，如果期望，前面提到的用户偏好可以至少部分地包括动态构建。通过一种方案，用户接口可以允许给定用户在提交服务请求时表达某些偏好。例如，在提出服务请求，可以给用户提供可允许偏好选项的候选列表，从而允许用户按照他们的意图和愿望来选择特定选项。

Claims (17)

1.一种方法，该方法用于与下述各项一起使用：

多个网络，包括独立的接入网络、控制网络和服务网络中的任何网络；和

多个服务终端用户；

所述方法包括：

在包含独立的接入网络、控制网络和服务网络中任何网络的所述多个网络与汇聚应用层之间提供服务汇聚架构；

使用所述服务汇聚架构，用于：

接收服务请求；

处理关于下述内容的所述服务请求：

用于支持所述服务请求的资源；和

对应所述服务请求的用户会话状态；

和

对应所述服务请求的用户偏好；

提供包括下述各项中至少一个的响应：

处理后的服务请求；和

对所述服务请求的汇聚的响应；

公布所述响应，以便促成支持所述服务请求。

2.如权利要求1的方法，其中接收服务请求包括：接收来自在所述服务汇聚架构外部的服务终端用户的服务请求。

3.如权利要求1的方法，其中接收服务请求包括：接收来自在所述服务汇聚架构外部的应用的服务请求。

4.如权利要求1的方法，其中接收服务请求包括：接收来自服务管理元件的服务请求，所述服务管理元件包含所述服务汇聚架构的一部分。

5.如权利要求1的方法，其中处理关于用于支持所述服务请求的资源的所述服务请求包括访问数据库。

6.如权利要求5的方法，其中访问数据库包括访问数据库，以便获得关于下述各项中至少一个的信息：

关于用于支持所述服务请求的至少潜在的可用资源的信息；

关于用于支持所述服务请求的至少潜在的可用资源的当前可用性的信息；

关于与至少潜在的可用资源对应的现有鉴权的信息，所述可用资源可以与支持所述服务请求相关。

7.如权利要求1的方法，其中处理关于对应所述服务请求的用户会话状态的服务请求包括：使用关于与所述服务请求相关的、终端用户的基本上当前会话状态的信息。

8.如权利要求7的方法，其中关于与所述服务请求相关的终端用户的基本上当前会话状态的信息包括下述各项中的至少一个：

关于特定终端用户是否具有当前活动会话的信息；

关于代表特定终端用户的当前活动的应用的信息。

9.如权利要求1的方法，其中处理关于对应所述服务请求的用户偏好的服务请求包括使用关于下述各项中至少一个的信息：

关于如何代表给定的服务受益者来促成服务的预先建立规则；

关于如何代表给定的服务受益者来促成服务的动态建立规则。

10.如权利要求9的方法，其中通过下述各项中的至少一个来至少部分地建立用户偏好：

启动所述服务请求的实体；

可以被用来促成所述服务请求的资源；

可以参与所述服务请求的实体；

所述服务请求的受益者；

将被用来促成所述服务请求的应用。

11.如权利要求1的方法，其中处理所述服务请求包括：将所述服务请求中的至少部分服务请求路由到资源处理器、会话状态处理器和偏好处理器中的每一个。

12.如权利要求1的方法，其中使用所述服务汇聚架构提供响应包括：将关于所述资源、所述用户会话状态、和所述用户偏好的信息提供给服务管理网络元件。

13.如权利要求12的方法，其中将信息提供给服务管理网络元件进一步包括：处理所述信息，以从用于处置所述服务请求的多个潜在方式中选择用于处置所述服务请求的特定方式。

14.如权利要求1的方法，其中公布所述处理后的服务请求以便促成支持所述服务请求包括：将关于处理后的服务请求的启用信息提供给下述各项中的至少一个：

服务请求的请求者；

至少一个资源所有者；

所述服务汇聚架构中的其它服务管理网络元件。

15.一种用于在服务汇聚架构中使用的装置，所述服务汇聚架构被部署在包含独立的接入网络、控制网络和服务网络中任何网络的多个网络与汇聚应用层之间，所述装置包括：

服务请求接收机；

服务请求路由器，该服务请求路由器在操作中被耦合到所述服务请求接收机；

资源评估器，该资源评估器在操作中被耦合到所述服务请求路由器，并被配置和设置为评估对应于支持所述服务请求的资源可用性；

用户会话状态评估器，该用户会话状态评估器在操作中被耦合到所述服务请求路由器，并被配置和设置为评估对应于支持所述服务请求的用户会话状态；

用户偏好评估器，该用户偏好评估器在操作中被耦合到所述服务请求路由器，并被配置和设置为评估对应于支持所述服务请求的用户偏好；

服务请求公布器，该服务请求公布器在操作中被耦合到所述资源评估器、所述用户会话状态评估器、和所述用户偏好评估器，并被配置和设置为公布处理后的服务请求响应，以便促成支持由所述服务请求接收机接收的服务请求。

16.如权利要求15的装置，其中所述服务请求接收机被配置和设置为接收来自服务终端用户、应用和服务管理网络实体中的任何一个的服务请求，所述服务管理网络实体包含所述服务汇聚架构的一部分。

17.如权利要求15的装置，进一步包括：

服务管理网络元件，所述服务管理网络元件接收来自所述资源评估器的关于资源可用性的信息，接收来自所述用户会话状态评估器的关于用户会话状态的信息，并接收来自所述用户偏好评估器的关于用户偏好的信息，并其使用所述信息来处理所述服务请求，并且从而将可公布的处理后的服务请求响应提供给所述服务请求公布器。

Images