Patent ID: 12244470

DETAILED DESCRIPTION

For the purpose of explanation, details are set forth in the following description in order to provide a thorough understanding of the embodiments disclosed. It will be apparent, however, to those skilled in the art that the embodiments may be implemented without these specific details or with an equivalent arrangement.

The use of adaptive domain randomization techniques may assist in bridging the simulation-to-reality gap. Given samples of real-world data, adaptive domain randomization techniques allow the training of a ML agent in a safe simulation environment, wherein the simulation environment has a data distribution that is close to the real world data distribution target. However, in order to provide a more complete solution to the simulation-to-reality gap problem in the context of distributed RL architectures with centralized training, several other issues remain to be addressed. In some application scenarios, real-world data samples are not readily available. Different deployments (in client nodes) of the same policy may observe different data distributions, and extraneous factors might induce data distributions experienced by client nodes to change over time. Further, in some systems, it may not be viable to transfer the whole set of observed data to a centralized server, and even where such a transfer is possible, privacy constraints might apply when transferring observed data to a centralized server.

Aspects of embodiments relate to the use of distributed RL, wherein training takes place in a server, and deployment of the resulting policy occurs at one or more independent client nodes, where its inference defines the behaviour of the client nodes. Aspects of embodiments may allow client nodes to adapt to the production data distribution before their activation, and may also allow monitoring of client node observed data distributions, which in turn may facilitate continual learning. Accordingly, aspects of embodiments may help address issues relating to the simulation-to-reality gap.

Embodiments of the present disclosure provide methods of operation of a client node for implementing RL, wherein the client node instructs actions in an environment in accordance with a policy, and also methods of operation of a system comprising the client node and a server.

FIG.2is a schematic overview of a DRL system20, which may perform methods in accordance with aspects of embodiments. The DRL system20ofFIG.2comprises a single server21and a plurality of client nodes22a,22b,22c,22dand22e(collectively referred to using the reference sign22). The DRL system20ofFIG.2shows five client nodes22; those skilled in the art will appreciate that larger or smaller numbers of client nodes may be used. Some DRL systems may also incorporate plural servers, which may be of particular use when modelling very complex environments.

As indicated by the arrows inFIG.2, each of the client nodes22may communicate with the server21, but there are typically no direct lines of communication between client nodes22. In some aspects of embodiments the server and the client nodes may be co-located, that is, may be contained within the same physical apparatus. However, typically the server and client nodes are located separately from one another, and communicate with one another using a suitable communication means (such as a wireless telecommunications system, wired telecommunications system, and so on). Whether or not the server and one or more of the client nodes may be co-located may depend on the trust model between the server and respective client nodes. In the embodiment shown inFIG.2, there is trust for the server to communicate directly with each of the client nodes but not for client nodes to communicate directly with each other—privacy between client nodes but trust in the server. If the server and one or more client nodes were co-located, that would make the one or more co-located client nodes more privileged than client nodes that were not co-located.

In some aspects of embodiments the DRL system20may form part of a wireless communication network such as a 3rdGeneration Partnership Project (3GPP) 4thGeneration (4G) or 5thGeneration (5G) network. Where the DRL system20forms part of a wireless communications network, the server and client nodes may be co-located and/or may be located in suitable components of the network. In some aspects of embodiments, the server21may form part of a Core Network Node (CNN), and the client nodes22may each form part of a base station (which may be 4th Generation, 4G, Evolved Node Bs, eNB, or 5th Generation, 5G, next Generation Node Bs, gNBs, for example).

A method in accordance with aspects of embodiments is illustrated byFIG.3A, which is a flowchart showing an operation method of a client node for implementing RL, wherein the client node instructs actions in an environment in accordance with a policy. The nature of the client node, actions, environment and policy are dependent on the specific system in which the method is used; taking the example where the environment is a telecommunications network as discussed above (or part of the same), the client node may be a base station (or may be incorporated in a base station), and the policy may cause the client node to instruct actions such as rerouting traffic in the telecommunications network, increasing network capacity, and so on. As a further example, the environment may be a traffic management system (or part of the same), the client may be the controller for one or more traffic lights, and the policy may determine the lighting sequence used for the lights to reduce congestion.

The method shown inFIG.3Ais performed by a client node. Any suitable client node may be used, for example, client node22a, b, c, doreofFIG.2.FIG.4AandFIG.4Bshow further client nodes401,451in accordance with aspects of embodiments. The client nodes401,451may perform the method ofFIG.3A.

A method in accordance with further aspects of embodiments is illustrated byFIG.3B, which is a flowchart showing an operation method of a server for implementing RL. As with the client node discussed above with reference toFIG.3A, the nature of the server, actions, environment and policy are dependent on the specific system in which the method is used; taking the example where the environment is a telecommunications network as discussed above (or part of the same), the server may be a core network node (or may be incorporated in a core network node), and the policy may cause the client node to instruct actions such as rerouting traffic in the telecommunications network, increasing network capacity, and so on. As a further example, the environment may be a traffic management system (or part of the same), the server may be a central control station for the traffic management system, and the policy may determine the lighting sequence used for the lights to reduce congestion.

The method shown inFIG.3Bis performed by a server. Any suitable server may be used, for example, server21ofFIG.2.FIG.5AandFIG.5Bshow further servers501,551in accordance with aspects of embodiments. The servers501,551may perform the method ofFIG.3B.

As shown in step S301ofFIG.3Athe method comprises identifying, at a client node401,451, one or more critical states of the environment (for which the client node instructs actions) for which a current policy used by the client node401,451provides unreliable actions. An environment state may be identified as a critical state where it differs substantially from environment states used to generate the current policy used by the client node401,451. A substantial difference in this context may be identified as a difference which influences the way the environment would respond to an action. As a result of the substantial difference between the critical state and the environment states used to generate the current policy, it is not certain that actions provided by the current policy would have the desired effect on the environment. Using the example wherein the environment is a telecommunications network, if the environment is in a critical state, an action proposed by a current policy with the intent of reducing packet losses may not have that effect, and may in some situations increase packet losses. As the actions proposed by the current policy when the environment is in a critical state may not have the desired effect on the environment, the actions proposed by the current policy are considered to be unreliable actions. The step of identifying one or more critical states may be performed in accordance with a computer program stored in a memory402, executed by a processor401in conjunction with one or more interfaces403, as illustrated byFIG.4A. Alternatively, the step of identifying one or more critical states may be performed by an identifier451as shown inFIG.4B.

Critical states may be identified in any suitable way, for example, by observations of the environment state, potentially in conjunction with comparisons of the observed environment state with environment states used to generate the current policy. Any suitable technique may be used to perform comparisons between observed environment state with environment states used to generate the current policy. Examples of suitable techniques are those based on Random Network Distillations (RNDs). RNDs are discussed in greater detail in “Exploration by Random Network Distillation” by Burda, Y. et al., available at https://arxiv.org/abs/1810.12894 as of 9 Nov. 2020.

In order to implement critical state identification techniques, such as RND techniques, the information used to train/retrain an MLS to generate a policy (to be used by a client node), may also be used to train/retrain a state classification model. In the training/retraining process, the state classification model may essentially memorise the training data. The trained/retrained state classification model may then be used to classify observed environment states; the classifications may comprise “critical” and “not critical”, and may in some aspects of embodiments include further sub classifications. The exact nature of the classifications may depend on the environment (telecommunications network, traffic management system, and so on) that the client node provides actions for.

In some aspects of embodiments the state classification model, once trained/retrained, may be distributed to one or more client nodes connected to a server501,551, potentially to all client nodes connected to the server501,551. Where the state classification model is distributed to one or more of the client nodes, these client nodes may then use the model (at the client node) to identify critical states. Alternatively, for client nodes that are not provided with the state classification model (for example, where the model is retained at the server), a sample of observed environment states may periodically be sent to the server, such that the server may use the state classification model to provisionally identify critical states, such provisional identification being confirmed by the client nodes.

In addition to or alternatively to identification of critical states using observations of the environment and/or state classification models, aspects of embodiments may utilise centralised information provided by the server to identify critical states. Any useful centralised information may be provide to the client nodes for use in identifying critical states. As an example of such information, it may be the case that training states of an environment in a particular implementation have values of a certain parameter within a given range; this range of the certain parameter could be provided to the client nodes to facilitate simple identification of critical states (states where the certain parameter is outside the given range).

Initially, client nodes may be provided with a policy by a server. Alternatively, the client nodes may be pre-loaded with a policy before or during deployment, including before the client nodes are connected to the server. The exact means by which the initial policy is provided to the client nodes may differ between nodes in a system, and in any event may be system dependent. The policy may be applied by the client nodes until one or more critical states are identified.

When one or more critical states have been identified, the client node may initiate transmission of a retraining request, as indicated in step S302ofFIG.3A. The step of triggering the transmission of a retraining request may be performed in accordance with a computer program stored in a memory402, executed by a processor401in conjunction with one or more interfaces403, as illustrated byFIG.4A. Alternatively, the step of triggering the transmission of a retraining request may be performed by a transmitter452as shown inFIG.4B. The client node may initiate transmission with the actual transmitting being performed by a further component (such as a further node), or alternatively the client node may initiate and execute transmission itself. The retraining request may be triggered by the identification of a single critical state, or when the number of observed critical states exceeds a threshold (which may be a predetermined threshold, may be set by the client node, may be set by the server, and so on). The retraining request comprises information relating to the one or more identified critical states; when the retraining request is received by the server as shown in step S305ofFIG.3B, the information may be used by the server in retraining a MLS to generate a new policy (see step S306ofFIG.3B). The step of receiving a retraining request may be performed in accordance with a computer program stored in a memory502, executed by a processor501in conjunction with one or more interfaces503, as illustrated byFIG.5A. Alternatively, the step of receiving a retraining request may be performed by a receiver551as shown inFIG.4B.

The server may initiate retraining of the MLS when a certain number of retraining requests are received from client nodes, wherein the retraining may use information relating to the one or more critical states from some or all of the received retraining requests. Alternatively, the server may initiate retraining when a single retraining request is received, using the information from that request. The step of retraining may be performed in accordance with a computer program stored in a memory502, executed by a processor501in conjunction with one or more interfaces503, as illustrated byFIG.5A. Alternatively, the step retraining may be performed by a trainer552as shown inFIG.5B.

The nature of the information included in the retraining request varies depending on the respective capabilities of the client node and server. In some aspects of embodiments, the retraining request includes a sample of identified critical states from the client node(s). The server may use a parameter generation model based on adaptive randomisation techniques, such as a BayesSim model, βt. BayesSim models are discussed in greater detail in “BayesSim: adaptive domain randomization via probabilistic inference for robotics simulators” by Ramos, F., Possas, R., & Fox, D., available at https://arxiv.org/abs/1906.01728 as of 9 Nov. 2020. The simulation parameter generation model may be trained (potentially using supervised learning) to output simulation parameters given a sample of observations that generated the simulation parameters. The trained model may then allow inference of simulator parameters given a sample of observations (in this case, observed critical states from client nodes). Therefore, by using a simulation parameter generation model, the server can specify simulation parameters that would induce environment states close to those identified as critical by the client nodes.

In some aspects of embodiments, as illustrated by the example shown in the process diagram ofFIG.6A, the server deploys a policy πθtto one or more client nodes i at time t, wherein the policy is based on system parameters θ, which are set during training. In addition to deploying the policy, the server also deploys a state classification model ϕtto one or more client nodes, typically the same client nodes to which the policy πθtis deployed. The example inFIG.6Ashows the policy and state classification model being deployed to client 1 and client n (at time t). The client nodes having received the state classification model can then use the model to locally (at the client nodes) to identify one or more critical states as discussed above. When the client nodes subsequently send a retraining request to the server, this retraining request may then include samples S of the critical states identified. In the example ofFIG.6A, client 1 includes samples S1in a retraining request to the server, and client n includes samples Snin a retraining request to the server. The samples S may comprise one or more (potentially all) of the critical states identified by the clients. In this example, when the server subsequently receives the retraining request (see step S305) comprising samples, the samples may then be used to generate simulation parameters (for example, using a parameter generation model as discussed above) to retrain the MLS as shown in step S306. The retrained MLS may then generate a new policy. The state classification model may also be retrained. The server may then deploy (see step S307) the new policy πθt+1and the new state classification model ϕt+1to the client nodes.

In further aspects of embodiments, as illustrated by the example shown in the process diagram ofFIG.6B, the server again deploys a policy πθtto one or more client nodes i at time t, wherein the policy is based on system parameters θ. Similarly to the example shown in FIG.6A, the client nodes (client 1 and client n) may then use the state classification model to identify one or more critical states. Prior to sending a sample of identified critical states to the server, the client node may then encrypt the sample before sending a retraining request including the encrypted sample to the server. Any suitable means may be used to encrypt the sample; in the example illustrated inFIG.6Ban encoding function ϵ is used to encrypt the sample at the client nodes, before the sample is sent to the server (see step S302). The encryption may also comprise modifying the sample of identified critical states in such a way that private information is obscured while the distribution of the data in the sample is maintained, for example, using differential privacy techniques. Alternatively or additionally, the sample of critical states may be encoded using a Bayesian network or Generative Adversarial Network (GAN), such that the data representative of the critical states may be retrieved and used by the server but the original data cannot be retrieved by the server. When the server receives the encrypted sample in the retraining request, as shown in step S305, the server decrypts the sample to obtain the critical states, before using the decrypted samples to generate a new policy (step S306) before initiating deployment (step S307) of new policy πθt+1and the new state classification model ϕt+1to the client nodes. Encrypting the samples before sending in this way may help to satisfy privacy preserving requirements which may exist in some systems, for example, in telecommunications networks wherein the state of the environment (a network state) may be considered confidential information.

Further aspects of embodiments may use different techniques to help satisfy privacy preserving requirements. As illustrated by example inFIG.6C, the information in the retraining request from a client node to a server may be information other than a sample of critical states (as is the case in the examples shown inFIG.6AandFIG.6B). In the example ofFIG.6C, the server deploys a policy πθtto one or more client nodes i at time t, wherein the policy is based on system parameters θ. In addition to deploying the policy, the server also deploys a state classification model ϕtto one or more client nodes, typically the same client nodes to which the policy πθtis deployed. The server further deploys a parameter generation model, such as a BayesSim model βt, to one or more client nodes, typically the same client nodes to which the policy πθtis deployed. The client nodes may therefore receive a triple (πθt, ϕt, βt) from the server. When the client nodes subsequently identify one or more critical states, these critical states may then be used in conjunction with the parameter generation model βtto infer simulation parameters, and these inferred simulation parameters may then be included in the retraining request to the server. By deriving the simulation parameters at the client nodes, the identified critical state samples can be retained at the client node rather than being sent to the server, which may satisfy privacy concerns regarding the state information. In this example, the server deploys (see step S307) a new policy πθt+1, new state classification model ϕt+1and new parameter generation model βt+1to the client nodes.

An overview of the aspects of embodiments discussed above with reference toFIGS.6A to6Cis provided by the flowchart ofFIG.7. The flowchart begins, at step S701, with the server sending a policy πθt(and potentially also a state classification model ϕtand/or parameter generation model βt) to a client node, and the client node applies the policy. Subsequently, at step S702, the client node identifies one or more critical states using the state classification model ϕt. If an encoding function is used to encrypt the critical states (as in the example shown inFIG.6B) or another encryption means as discussed above, then the critical states may be encoded at step S703—True. Otherwise, if no encryption is used (S703—False), then the method proceeds to step S704with unencrypted critical states. At step S704, if the parameter generation model βtis available at the client node (S704—True, as in the example shown inFIG.6C) then simulation parameters may be inferred and these inferred simulation parameters sent to the server in a retraining request. If a parameter generation model βt+1is not available at the client node (S704—False), then the critical states may be sent in the retraining request either encoded or not depending on whether S703was True or False. Finally, at S705, the server receives the retraining request and retrains the MLS to generate policy πθt+1(and potentially also state classification model ϕt+1and/or parameter generation model βt+1).

When a new policy (and potentially new state classification model and/or new parameter generation model) have been generated by the server, the server then performs deployment. The distribution of the new policy (and potentially new state classification model and/or new parameter generation model) is shown in step S307ofFIG.3B. The step of distributing the new policy may be performed in accordance with a computer program stored in a memory502, executed by a processor501in conjunction with one or more interfaces503, as illustrated byFIG.5A. Alternatively, the step of distributing the new policy may be performed by a distributor553as shown inFIG.5B. The nature of the deployment varies between systems, and may also vary between client nodes within a system.

For some client nodes, the server may provide a periodic update of the policy; the period of the update may also be dependent upon the nature of the system; for systems where the environment develops rapidly periodic updates may be provided on an hourly basis, while for systems that vary over longer time frames the policy updates may be provided weekly or over an even longer time frame. Where periodic updates are used, the update timing may be scheduled for a period when the client nodes typically experience comparatively low demand, for example, for a telecommunications network wherein the client nodes are or form part of base stations, the periodic updates may occur at 3:00 am local time when the level of communications traffic experienced by base stations would typically be quite low.

For some client nodes, the server may provide on demand updates of the policy. The client node may then receive an updated policy when the client node requests the policy from the server. The client node may request the policy when sending the retraining request, for example, the client node may indicate an occasion in the future when the client node will be available to receive an updated policy. Alternatively, the client node may send a further communication to the server requesting a policy update.

For some client nodes, the server may provide policy updates on an opportunistic basis, based on a current state of the server and the client node. These opportunistic updates may be provided whenever both the server and client node are in a suitable state. As an example of this, the server may monitor or may receive updates detailing a current workload of the client node. When the server (that has a policy update to provide and is in a suitable state) determines that the client node has a low workload, the server may provide the policy update. Where a server is connected to a plurality of client nodes, the policy update may be provided to all of the client nodes simultaneously.

As shown in step S303ofFIG.3A, the one or more client nodes receive the new policy from the server. The step of receiving the new policy may be performed in accordance with a computer program stored in a memory402, executed by a processor401in conjunction with one or more interfaces403, as illustrated byFIG.4A. Alternatively, the step of receiving the new policy may be performed by a receiver453as shown inFIG.4B. The one or more client nodes then instruct actions based on the received new policy, as shown in step S304. The step of instructing actions may be performed in accordance with a computer program stored in a memory402, executed by a processor401in conjunction with one or more interfaces403, as illustrated byFIG.4A. Alternatively, the step of instructing actions may be performed by an instructor454as shown inFIG.4B. As discussed above, the nature of the actions instructed is dependent on the environment in which the system operates.

Typically, following a policy update, the client nodes continue monitoring the environment to identify further critical states, that is, critical states for which the actions instructed in accordance with the new policy may not be reliable. If a client node identifies a further critical state, a further retraining request may subsequently be sent and the method ofFIG.3AandFIG.3Bmay be repeated. The iterative nature of the method is illustrated byFIG.8. For simplicity,FIG.8illustrates an aspect of an embodiment in which a server and a single client node are present, and in which retraining occurs when a single retraining request is received by the server from the client node.FIG.8begins at time t−1, with a retrain request sent to the server. The server performs the retraining of the MLS and provides new policy πθtto the client i, which implements the policy. At some point after implementing policy πθtthe client i then identifies a critical state, and sends a further retraining request to the server, which retrains the MLS and provides new policy πθt+1to the client i, which implements the policy. At some point after implementing policy πθt+1the client i then identifies a critical state, and sends a further retraining request to the server, and the iterative process continues.

As an example of how aspects of embodiments may be implement, in an example implementation the client node may be a base station (or part of a base station) used in the environment of a telecommunications network, and the server may be all or part of a core network node. The client nodes may make measurements that allow the current state of the network to be observed (network throughput, round trip time (RTT), packet losses, and so on); these measurements may constitute all or part of an observation of the network. When creating policies for such client nodes, simulation parameters taken into consideration by the server may include the sizes of queues, number of UEs competing for base station resources, any bottlenecks in the network, and so on. The choice of such simulation parameters induce the state distributions observed by the agent during training. Therefore, they define the range of the observations for which the agent will be prepared to act after deployment. The server would produce a policy to map observations (network throughput, round trip time (RTT), packet losses, and so on) to actions α that would lead to good performance. The same observations would be used to train a parameter generation model and a state classification model. If a base station subsequently observes a network state which is not provided for, for example a RTT which is much higher than expected, the base station may identify this as a critical state and the procedures discussed above may be implemented.

As a consequence of the identification of critical environment states and updating of policies, systems in accordance with aspects of embodiments (including systems implemented in telecommunications networks) may adapt to evolving operational environments, and provide reliable actions over an extended duration. Further, as policies may be shared across multiple client nodes, a given client node may be prepared for environment states which have not previously been observed by that client node (where such a state has been observed by another client node and policies generated accordingly); the resilience of the system is thereby improved. Also, as the policies are generated at a server and then distributed to client nodes, the client nodes themselves are not required to possess the capability to generate policies, which may allow simplified client nodes to be used.

It will be appreciated that examples of the present disclosure may be virtualised, such that the methods and processes described herein may be run in a cloud environment.

The methods of the present disclosure may be implemented in hardware, or as software modules running on one or more processors. The methods may also be carried out according to the instructions of a computer program, and the present disclosure also provides a computer readable medium having stored thereon a program for carrying out any of the methods described herein. A computer program embodying the disclosure may be stored on a computer readable medium, or it could, for example, be in the form of a signal such as a downloadable data signal provided from an Internet website, or it could be in any other form.

In general, the various exemplary embodiments may be implemented in hardware or special purpose circuits, software, logic or any combination thereof. For example, some aspects may be implemented in hardware, while other aspects may be implemented in firmware or software which may be executed by a controller, microprocessor or other computing device, although the disclosure is not limited thereto. While various aspects of the exemplary embodiments of this disclosure may be illustrated and described as block diagrams, flow charts, or using some other pictorial representation, it is well understood that these blocks, apparatus, systems, techniques or methods described herein may be implemented in, as non-limiting examples, hardware, software, firmware, special purpose circuits or logic, general purpose hardware or controller or other computing devices, or some combination thereof.

As such, it should be appreciated that at least some aspects of the exemplary embodiments of the disclosure may be practiced in various components such as integrated circuit chips and modules. It should thus be appreciated that the exemplary embodiments of this disclosure may be realized in an apparatus that is embodied as an integrated circuit, where the integrated circuit may comprise circuitry (as well as possibly firmware) for embodying at least one or more of a data processor, a digital signal processor, baseband circuitry and radio frequency circuitry that are configurable so as to operate in accordance with the exemplary embodiments of this disclosure.

It should be appreciated that at least some aspects of the exemplary embodiments of the disclosure may be embodied in computer-executable instructions, such as in one or more program modules, executed by one or more computers or other devices. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types when executed by a processor in a computer or other device. The computer executable instructions may be stored on a computer readable medium such as a hard disk, optical disk, removable storage media, solid state memory, RAM, etc. As will be appreciated by one of skill in the art, the function of the program modules may be combined or distributed as desired in various embodiments. In addition, the function may be embodied in whole or in part in firmware or hardware equivalents such as integrated circuits, field programmable gate arrays (FPGA), and the like.

References in the present disclosure to “one embodiment”, “an embodiment” and so on, indicate that the embodiment described may include a particular feature, structure, or characteristic, but it is not necessary that every embodiment includes the particular feature, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same embodiment. Further, when a particular feature, structure, or characteristic is described in connection with an embodiment, it is submitted that it is within the knowledge of one skilled in the art to implement such feature, structure, or characteristic in connection with other embodiments whether or not explicitly described.

It should be understood that, although the terms “first”, “second” and so on may be used herein to describe various elements, these elements should not be limited by these terms. These terms are only used to distinguish one element from another. For example, a first element could be termed a second element, and similarly, a second element could be termed a first element, without departing from the scope of the disclosure. As used herein, the term “and/or” includes any and all combinations of one or more of the associated listed terms.

The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the present disclosure. As used herein, the singular forms “a”, “an” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises”, “comprising”, “has”, “having”, “includes” and/or “including”, when used herein, specify the presence of stated features, elements, and/or components, but do not preclude the presence or addition of one or more other features, elements, components and/or combinations thereof. The terms “connect”, “connects”, “connecting” and/or “connected” used herein cover the direct and/or indirect connection between two elements.

The present disclosure includes any novel feature or combination of features disclosed herein either explicitly or any generalization thereof. Various modifications and adaptations to the foregoing exemplary embodiments of this disclosure may become apparent to those skilled in the relevant arts in view of the foregoing description, when read in conjunction with the accompanying drawings. However, any and all modifications will still fall within the scope of the non-limiting and exemplary embodiments of this disclosure. For the avoidance of doubt, the scope of the disclosure is defined by the claims.