JP2008506209A - Systems and methods for risk assessment and management in various systems and subsystems - Google Patents

Abstract

The present invention includes a system for risk management associated with at least one business process. The system is communicable to a first node that forms at least a portion of a plurality of communicable connection nodes for collecting at least one risk-related data value associated with at least one document. Connected to receive at least one risk related data value and evaluate at least one document related to the at least one risk related value according to the at least one risk related value against at least one of the plurality of risk categories And a second node of the plurality of communicable connection nodes. Furthermore, the present invention includes a method for managing system risks associated with at least one business process.
[Selection] Figure 1

Description

(Cross-reference of related applications)
This application is a US patent application serial number 10/895, filed on July 20, 2004 under the name “SYSTEM AND METHOD FOR SUPPLY CHAIN COLLABORATIVE RISK MANAGEMENT”. No. 014, and internationally by the Patent Cooperation Treaty filed on June 8, 2004 under the name “A SYSTEM AND METHOD FOR RISK DETECTION, REPORTING AND INFRASTRUCTURE” (Risk Detection, Reporting, and Infrastructure). Each of which is hereby incorporated by reference in its entirety as if set forth in its entirety in connection with Application No. PCT / US / 18218. It is incorporated.

  The present invention relates to the field of risk management, and more particularly to joint risk analysis of systems and subcomponents including business processes of industrial networks and related processes of documents and messages related to risk conditions.

  Risk-based decision making is an essential part of managing virtually any type of business. For example, banks and investment institutions assess risks and make risk decisions for investments, loans, and other transactions based on these assessed risks. For example, a financial institution examines risks including foreign exchange risk, reputational risk, credit risk, and operational risk when making a deal with a counterparty, especially when making decisions about type, cost, and method There is a case. Insurers can make similar decisions to assess risk versus reward and issue insurance policies based on the probability of claims and the size of these expected claims. In such cases, available and appropriate historical data can be used to assist in decision making regarding current and future actions.

  In addition, industrial network processes such as commodity trade are often at risk as well. For example, global commodity transport is subject to a variety of risks including, among other things, theft, smuggling (including terrorists) or smuggling, falsification of goods, or delivery of nuclear, radioactive, bio, chemical, or ordinary bombs, materials or weapons by terrorists. May be exposed. Legal and physical management of goods in transit includes, for example, manufacturers, distributors, intermediaries, financial operators, truckers, maritime carriers, certain integrated logistics companies, customs brokers, Global supply chain security can be difficult as it varies between different entities. Thus, for example, various logistics entities, including freight forwarders, third-party logistics operators, and major logistics operators can be involved and relevant risk information can be provided, making international logistics arrangements increasingly complex. It is becoming.

  Monitor the facilities, equipment, processes, and systems that make up the global supply for risk factors, for example, specific containers or items along a continuum of risks measured with strictness from within tolerance to outside tolerance It can enable decision makers to determine whether or not they exhibit a certain level of risk. By accurately analyzing and ranking the risks, businesses and governments can focus on high-risk shipments, or shipments that are perceived as potentially dangerous, or resources that respond to dangerous shipments. The ability to share certain information upstream, downstream, and throughout the supply chain, thereby enabling supply chain members to jointly manage risk, is the key to improving overall supply chain security. can do.

  The need for information sharing to reduce security risks can be significant. For example, the global transportation industry, such as the global aviation industry, is trying to serve customers by having a regularly scheduled service and a sufficiently high frequency of services to address customer needs. However, very few, if any, maritime carriers operate enough equipment to provide the necessary coverage. Thus, marine carriers often arrange freight shipments together to expand their individual scope. In practice, almost all maritime carriers then reserve containers that will be transported on competitors' ships.

  Techniques have been developed to assess risk, share information, and support decisions on actions based on the assessed risk. However, risk management processes and architectures in business processes have hitherto been difficult to deploy across one or more local and external business and technology domains. Furthermore, in existing systems, once a risk-based decision is made, it will be implemented, for example, re-liquidation, insurance qualification, or automatic execution and / or sale for insurance claims. Various actions may be difficult to implement, including refusing transactions or initiating new transactions or transitions, and / or alerting appropriate personnel.

  Data security control uses risk assessment for data systems (eg, networks and computers). Appropriate or inappropriate actions (host / network system) based on specific policies that describe what is within and outside tolerance and can include consideration of “signatures” Pattern) can be allowed or denied. The history information can be retained, in part, to determine that it can be within an acceptable range based on past actions. Thus, current and / or future actions can be permitted or denied based on what was permitted in the past. One such implementation of data security control is known as a firewall.

  Intrusion detection systems (IDS) can be used in computer systems and networks. IDS can be used to detect and identify unauthorized use of a computer. In general, IDS looks for specific patterns or signatures through logs, network traffic, file modifications, and other available sources to detect malicious activity. These signatures can be identified using, for example, a finite state machine, simple pattern matching, or special algorithms. Many IDSs tend to issue false positive and false negative alerts. False positives occur when IDS identifies problems such as unauthorized actions that have not occurred. False negatives occur when IDS does not detect a problem that has occurred.

  Given the dependence on historical data and the possibility of false positives and false negatives, a simple negative pattern signature may be desirable but not sufficient to fully protect the system. The negative signature approach deals with identifying unauthorized ones. The complementary or positive signature approach specifically defines what is permitted or at least acceptable within an acceptable deviation.

  Rules, also referred to herein as policies, indicate those actions that can be specifically allowed and / or those actions that can be specifically denied. Rules specify the parameters within which transactions are conducted. A dynamic rule is a rule that allows various responses to change over time according to specific inputs, such as a response changing based on various considerations.

  Ideally, the rules used for the IDS test are dynamic rules. However, since rules can often be “hard-coded” as part of the security system's binary code, the rules cannot be truly dynamic. The absence of dynamic rules creates problems in a variety of situations, including, for example, when security software is updated (eg, when executable code becomes long and slow and the machine needs to be stopped to upgrade). .

  In addition, business processes can typically be much more complex than rules associated with intrusions on computer systems that operate these business processes. For example, the information flow may come from multiple entry points and may not arrive at the center point. To hide the lack of dynamic rules and solve the ever-increasing complexity of business processes, network-based firewalls are more commonly known as network address translation, more commonly known as NAT, or more commonly as PAT. The IP address can be changed via port address translation to hide certain internal network settings. However, with such “coordination”, the visible content has changed, but the messaging context remains the same. Such adjustments are inefficient to conceal or correct changes or termination of business processes for a particular transaction type, and similarly, not to change the authorization or disapproval of a particular transaction or state over time. It may be efficient. Furthermore, such coordination cannot dynamically add various monitoring or control techniques in a simple manner that can identify and resolve various risks throughout the enterprise distributed process.

  Such computer systems and physical networks that implement rules to avoid risks can use rules to implement information sharing requirements, which can result in tension between entities in the supply chain. There is sex. For example, there is a type of business known as a complex integrated carrier (NVOCC), which can obtain cargo directly from end users and issue bills of security to customers in exchange for cargo. By definition, NVOCC does not operate a ship and therefore entrusts the cargo to a carrier in exchange for subsequent bills of transport. In this case, specific customer, shipment, and container data can exist in the NVOCC.

  Information sharing also occurs in a mixed load situation. Many people and organizations try to transport goods without completely filling up the container load. A consolidator may be involved, may issue bills of lading or other proprietary documents to the customer, and may attempt to fill the shipping compartment by consolidating several loads in a single container There is sex. In such a configuration, the consolidator can maintain customer and cargo data.

  Carriers can carry a significant percentage of the cargo of other carriers, NVOCCs, and consolidated carriers on their ships. This freight can be transported on a common freight basis, i.e. if the freight charge is paid and there is no reasonable ground to refuse the freight, the container needs to be accepted for freight.

  The risk profile of a particular container or item can be affected by several factors. Data related to these factors can be maintained by several different entities, all of which should allow the container to be loaded onto a container ship, delivered to the port, or It can be important to determine if it should be released from government storage. Furthermore, it may not be sufficient to determine aggregate risk through analysis of a single container's risk profile. The relationship between multiple containers, shipments, and other factors can be needed to determine the overall risk of undesirable events. Risk-related data can be generated or maintained by several different entities.

  In addition, companies participating in the global supply chain may be required to resolve security issues, such as when there is a potential terrorist threat. However, at present, there is no global standard to be met in this situation, and it is therefore difficult for companies to recognize what to do or how to respond. Shipped cargo frequently passes certain choke points such as mixed loading centers, container premises, maritime terminals, and container ships, where cargo from one supply chain can mix with cargo from other chains There is sex. A secure supply chain may be exposed to certain risks that arise as a result of access to cargo that is being moved in a less secure manner. Since the determinant is the weakest link, the expense of improving the security of one chain or one company's chain may not be effective. Therefore, all companies need to follow similar standards. Without compulsory or optional standards or guidelines, companies may be left to individually determine the degree of security sufficiency, and they may be legally responsible for inadequate responses when events occur. On the other hand, spending more on security than competitors can leave the company at a disadvantage in the business, hindering improved response. It may be desirable for all parties to work towards a common or standardized baseline of security enforcement. A shipping entity may be required to transport cargo that is reserved by a separate booking entity and tracked by a separate tracking entity, and the security and risk-related procedures that these other entities follow are It is preferable to understand that it is sufficient to meet the security and risk requirements of the transportation entity.

  Efforts to implement supply chain-related joint risk management can be complicated by the fact that some of the subscribers in a single supply chain may be competing with each other. For example, this is incorporated into a maritime business model where carriers, NVOCCs, consolidators, and others reserve container movements with carriers on a spot basis or according to a shipping contract. The booking entity may wish to hold information from the shipping entity, especially customer data, so that the freight entity avoids the booking entity and tries to contact the customer directly. .

  The insurance industry can compare premiums and related revenue against event-related payments and related expenses when deciding whether to provide insurance coverage lines. This decision can be difficult with regard to terrorism-related risks. Unlike natural occurrences, terrorist actions cannot be predicted with respect to the number of incidents or the magnitude of the damage involved. In addition, certain risks such as nuclear or certain radiation risks may not be guaranteed. These specific risks tend to be considered catastrophic risks that cannot provide insurance coverage economically. As is known to those skilled in the art, financial institutions such as banks are sensitive to risk parameters within their customer base, and financial costs can vary depending on compliance or level of compliance. There is. Both buyers and sellers will want to monitor risk factors that may affect the fulfillment of either delivery or payment of goods. In another view, various entities will want to limit the risks borne compared to other entities in the system.

  Some of the risks that can be resolved in decision making within any system are whether the data originates from an authorized and authorized source, whether the data from an authorized and authorized source is corrupted or unauthorized It can be an awareness as to whether changes have been received without being made.

  Risk information associated with a particular document, shipment, or supply chain element can be maintained by various parties responsible for the costs associated with collecting that information. This information is useful and other entities may wish to purchase it on some commercial basis. This formal mechanism for information structuring, pricing, and exchange is not available. Accordingly, there is a need to be able to incorporate information pricing models into data exchange protocols.

  Furthermore, security and risk information transfer between supply chain subscribers, national or international organizations for decision support, and / or adapted from one supply chain subscriber to another directly or through an intermediary device. There is a need to define a responsibility representation for compliance with security or risk standards.

  Thus, risk can be monitored efficiently, allowing flexibility in modifying, communicating or updating the risk policy, and sufficient security and risk for the transport entity to comply with any external or internal compliance requirements. There is also a need for systems, methods, and devices that provide related information or descriptions.

US Patent Application Serial No. 10 / 895,014 International Application No. PCT / US / 18218

  The present invention includes systems and methods for risk management associated with at least one business process. The system is communicable to a first node that forms at least a portion of a plurality of communicable connection nodes for collecting at least one risk-related data value associated with at least one document. Connected to receive at least one risk related data value and evaluate at least one document related to the at least one risk related value according to the at least one risk related value against at least one of the plurality of risk categories And a second node of the plurality of communicable connection nodes. The second node also implements at least one risk category according to at least one risk policy approved by a central node of the plurality of communicable connection nodes for at least one business process, and at least one It is further determined whether at least one document risk exists according to a rating score for the at least one document according to the risk category.

  A method for managing risk includes collecting at least one risk-related data value associated with at least one document, and at least one document associated with the at least one risk-related data value from at least one of a plurality of risk categories. Evaluating for one and implementing at least one risk category for at least one business process according to at least one risk policy approved by a central node of the plurality of communicable connection nodes. And determining whether there is a risk for at least one document according to a rating score for the at least one document according to at least one risk category.

  Thus, the present invention can monitor risk efficiently and provides sufficient security and risk to comply with any external or internal compliance requirements while providing flexibility in modifying, communicating or updating risk policies. Systems, methods, and devices are provided that provide related information or expressions to a transportation entity.

An understanding of the present invention can be facilitated by considering the following detailed description of the preferred embodiments of the invention with reference to the accompanying drawings, in which like numbers refer to like elements.
The illustrations and descriptions of the present invention have been simplified to illustrate relevant elements for the purpose of simplifying the understanding of the present invention, while others found in representative risk management systems and methods using the present invention. It should be understood that many elements of are excluded for purposes of clarity. One skilled in the art can appreciate that other elements and / or steps are desirable and / or required in the implementation of the present invention. However, such elements and steps are known in the art and are not described herein as they cannot help a full understanding of the present invention. The disclosure herein is directed to all such changes and modifications to such elements and methods known to those skilled in the art.

  Risk-related data can be generated and maintained by several different entities. For example, in an industrial network environment, information about different parties involved in a transaction, such as the identity of the importer, consignee, source manufacturer, or distributor and information about them, may be initially or ultimately specific containers. May be owned by the entity that reserves the transfer. Information about facilities that can pack and store containers during transit is initially or ultimately maintained by any number of parties, or third party auditors or evaluation agencies that perform on behalf of those parties. can do. Information about containers in operation can be maintained by inland (or maritime) carriers such as trucks, railroads, or cargo ships that carry the containers. Information about the route can be maintained by the transportation or tracking entity. A sufficient amount of this information is available to the shipping entity and, in some cases, government authorities, so that appropriate risk-based decisions can be made as to whether or not a particular container or cargo item is transported. Is obvious. In addition, under the current regulatory overview, the carrier or NVOCC submits appropriate security-related information to US customs authorities for containers entering US-controlled ports, with or without unloading, in accordance with 24-hour advance notice rules. responsible. Other countries have or are expected to have similar requirements.

  For example, shipped cargo frequently passes certain chokepoints or bottlenecks such as consolidation centers, container premises, maritime terminals, and container ships, where cargo from one supply chain is from another chain. May be mixed with cargo. A highly secure supply chain can be exposed to several risks that result from approaching cargo moving in a less secure manner. Spending to improve the security of one chain or one company's chain may not be effective. Thus, all companies that enter the supply chain need to follow a similar set of standards, rules, or policies. In this regard, it may be desirable for all parties to work towards a common baseline of security enforcement.

  In addition, the shipping entity may be required to transport cargo that is reserved by a separate booking entity and tracked by a separate tracking entity, and security and risk-related procedures that these other entities follow. Is preferably understood to be sufficient to meet the security and risk requirements of the carrier. Although various mechanisms can be envisaged to gain this understanding, according to aspects of the present invention, security and risk standards can be followed or implemented by baseline or standardization.

  In one example, an insurer can compare premiums and related revenue against incidental payments and related expenses when deciding whether to provide an insurance coverage line. This determination can be difficult, for example, with regard to terrorism-related risks. Unlike natural occurrences, terrorist actions cannot be predicted with respect to the number of incidents or the magnitude of the damage involved. However, as demonstrated by the 2002 US Terrorism Risk Insurance Act (TRIA), insurance companies have strong political leadership to provide compensation for terrorist behavior. TRIA provides a mechanism to request insurance companies to provide terrorism compensation, and provides government-provided damage compensation assistance of approximately $ 100 billion ($ 100,000,000,000).

  Furthermore, certain risks such as nuclear or certain radiation risks cannot be compensated by insurance. These particular risks tend to be considered catastrophic risks that cannot provide insurance coverage economically. However, even though some of this risk will ultimately need to be diverted to the public sector, it is in the interests of government, business and society that commercial risk transfer products take on at least some of this risk. come true. Standard evaluation and compliance monitoring can be key to these risk controls. As is known to those skilled in the art, financial institutions such as banks are sensitive to risk parameters within their customer base, and financial costs can vary depending on compliance or level of compliance. There is. Banks may want to monitor certain information or receive certain information or indications regarding implementation in order to set, maintain or adjust financial rates.

  Various entities within the system will want to limit the risks borne compared to other entities within this system. For example, one entity that may be a node in this system may wish to restrict the type of information it receives from another node, or the dollar value of a transaction that this entity is involved in. May want to be restricted to another node. These limits can be set on a system-wide basis or a bilateral basis between nodes.

  Part of the risk in a given system is whether the data originates from an authorized and authorized source, and the data from the authorized and authorized source is received without corruption or unauthorized changes It can be in recognizing whether or not. Various technologies exist within the infrastructure that resolve source authenticity and data integrity. Such techniques include, but are not limited to, for example, symmetric and public key encryption techniques. Public key cryptography techniques include both certificate-based ones such as VerisSign certificates and non-certificate-based ones such as account authority-based digital signature models, including known account authority digital signature model techniques. Can do. Other methods are known to those skilled in the art.

  In a first aspect of the invention, systems, methods, and devices are provided that efficiently monitor risk and allow flexibility in modifying or updating at least one risk policy. The present invention monitors a risk associated with at least one business process and evaluates at least one of a plurality of document instances, each of which includes a plurality of document values for a plurality of risk categories. Implementing a plurality of risk categories according to a stage, at least one acceptable risk policy approved for at least one business process, and according to an approval rating of at least one document of the at least one risk category. Qualifying at least one of the following.

  Referring now to FIG. 1, a flow diagram illustrating the evaluation of a document 101 against a risk policy 107 that can include several values 104 is shown. The document 101 may be a physical document converted to electronic form, for example by web access, web service, gateway, optical character recognition (OCR) or scanning, one or more corresponding to one or more values attached or associated The illustrated exemplary system can be provided in various ways, such as by one or more physical items that can have more features, or by any similar method known to those skilled in the art. If the document is a physical item, such as paper, equipment, or other cargo, this document shall be given or associated with this document a signifier such as a barcode, wireless tag, or the like. This signifier shows the characteristics associated with the physical document. For example, sensing signifie can cause the electronic system associated with the sensor to access values associated with the physical document. The present invention is not limited by the manner in which the document or its conversion to electronic form is provided.

  As used herein, document 101 is a value that is important to, or possibly related to, security in business systems or processes, particularly business systems or processes such as freight, insurance, or the like. Yes, or represents or includes this value, or can be associated with this value. For example, the value can be a field available in the record as is known in the art, or another type of data or information regarding a business system or process. Document 101 can also be a plurality of documents, or can initially have a paper-based definition or structure, or can initially have physical properties, or can be established or structured. It can be a subset or superset of one or more documents, which can be of different data sources. Such a data source or paper-based or physical definition can include or be associated with a value that includes values obtained from other sources external to one or more documents. References to document 101 may include, but are not limited to, references to any one field or all fields in or associated with the document.

  Documents can be defined in the risk detection system (“RDS”) and its associated infrastructure. For example, a script language, a technology that implements a GUI (graphic user interface), or other expressions can be used. According to an aspect of the present invention, an extensible language such as XML [XML] can be used. The XML used may be in accordance with “Survey Sample: Web Form Design in ASP.NET” by Allen Wagner. In addition, any of a variety of computing aspects, languages, or scripts, including XML, can be incorporated into the present invention.

  By way of illustration, the XML code can include:

  According to this aspect of the present invention, the specification of the document 101 such as a survey can be defined. Other methodologies for incorporating existing database definitions will be apparent to those skilled in the art, but such document specifications can create data definitions. SourceType can be a web-based input, for example MasterDB. Store information in the appropriate record under a database such as BldSecurity. As an illustration of this, a website that can be deployed is www. xxx. com / survey.

  The Question can be given a number using an ID, and in this embodiment, it can be displayed depending on whether or not the “Visible” flag is set to “Yes”. In this example, the question to be displayed is provided in “Text” and the type of response is in “Type”. Any number of questions can be used, and any type of ID known in the art can be used. Type can include, but is not limited to, for example, “character”, “numeric”, “freeform”, “multiple choice”, Boolean, or the like. Other types will be apparent to those skilled in the art and can be validated against the correct or incorrect input type.

  In the above example, “Answer” can have multiple purposes and can usually represent the input of the submitter. The submitter can be a person, process, or any source, such as automatic, manual, electronic, or mechanical input, as a non-limiting example.

  In the above embodiment, “Tag” can be used as the variable name of the question. In the above example, the CountryValue (defined by ID = 1) in the calculation field of ID = 2 can see the riskvalue (risk value) in the CountryRriskTable indexed by the CountryValue. The answer to the question in this example can be the Country risk value multiplied by four, and in this example the answer is invisible during input.

  The above example illustrates web-based input. It will be apparent to those skilled in the art that other input forms may be provided. For example, the question is not displayed and can take the form of an electronic query, such as a query that accesses information from a digital format such as a database, as an “answer” or input. The input in response to the query can be any outgoing electronic packet representing information in a data store, such as a database, directory, or flat file, for example. In such a case, the data description can describe how to obtain the value to be input. For example, the data description can represent that the value is a particular field in the database table, or the first X bits starting with bit Y in the data value. If “Visible =“ No ””, the input in response to the question may also be a calculated value rather than being obtained from human input.

  FIG. 4 represents an exemplary use of “Tag” and “compute”. Again, the document 101 can include any number or series of values. For simplicity, values 1 through 4 (above line 402) can be visible to the user in this example, and the remaining values below the line can be invisible to the user. As shown, the value n403 can be a copy of the value 1 in this embodiment. The value 5 405 can be obtained from a local store such as the database 406, for example. Values 5 and 6 can each be identified by tags, which are for illustrative purposes and can be represented as TAG_V5 (eg <Answer Tag = “TAG_V5”>) and TAG_V6, respectively. More complex calculations 404 can be any function f required by the security system and capable of computation, and visible and invisible values can be used. The result of the function f can lead to the required or required position, such as the placement of the result as the value 6 in this example. This can be coded as <Answer Compute = “TAG_V5 * TAG_V6”> as in the above embodiment.

  Returning now to FIG. 1, the risk category 102 is based on the acceptable risk of one or more business processes, which can classify the risk into various groupings to solve certain objectives. be able to. As an example, in [BS7799], information security is characterized as maintaining confidentiality (C), integrity (I), and availability (A). In risk management applications, the system can typically be evaluated separately based on various unique or applicable criteria, and such evaluation can typically be analyzed simultaneously. In the BS7799 embodiment described above, using grades for confidentiality, integrity, or availability, the controls required to meet each criterion are different and may in fact be inconsistent. . For example, in container shipping, it is expected that the evaluation of the process that controls the loading of goods and the inclusion of goods in the container will be evaluated by separate and potentially conflicting risk-related criteria.

  Without limitation, risk categories (Rsic Categories) referenced in FIG. 1 can be specified, for example, in XML or a similar schema. For example, the XML coding of such risk classification can include:

  However, the risk category can be an aggregate of risks for some attributes of the risk, rather than a specific risk aspect of some attributes of the risk. That is, the aggregation can be 1 to 1106, many to one 109, or one to many 105. Thus, the exemplary XML-A described above can be modified as follows.

  In XML-B, when the response to question 3 is Yes, 50 is added to RiskCat1, and 20 is added to RiskCat2. Subtraction, addition, division, multiplication, multiplication of constants or coefficients, or other calculation functions can be used, as shown by AnserID = “2”. Furthermore, the calculation can be performed at each stage. For example, when the answer A is YES, 3 is multiplied, and when the result is greater than 50, the question B is asked and when the answer is the answer C, 3 is subtracted. In addition, data from one or many or other sources can be retrieved when performing such calculations. For example, an input value (eg, “Add (thisInput * 5)”) may be performed with function F, the response (ie, thisInput) multiplied by 5, and the result added to the appropriate risk category. The function may be complex and may include other programming aspects, such as incorporating programming scripts using Java or another high level language. Without limitation, a programming script or calculation is a tag such as “CountryValue” described in XML-A in a function to represent a value, such as a value in a database or web location table, or as an index to look for a value A name can be specified.

  Risk categories can be analyzed according to one or more risk policies 107. As a result, the value of document 101, and more specifically document 101, can be evaluated against the risk policy according to one or more required risk policies.

  In the following embodiment, a plurality of rules can be applied, using "Action", that is, a special language, or a known language such as Basic, Visual Basic, C, C ++, Java, or Perl. The script that has been executed is executed when “Criteria”, which is a script that returns true or false, is evaluated. As will be appreciated by those skilled in the art, the following examples are not limited to a particular language and can be additionally implemented, for example, in XML.

The above examples are traced from top to bottom in this document. Some of the following noteworthy functions can be included as examples, but are not limited thereto.
Exit (): Exit and do not test for any additional rules.
Request (<Group (Group)>, <FLAG>, <effective date>): Acceptance of a document requires that someone from the group <Group> receive it. The user is provided with a flag value (e.g., RED condition) to help understand the rigor of the problem, and <effective date> indicates that the user accepts the document once the group user receives the document. You can describe the effective date.

  Notification (<type)>, <user name>, <subject>, <Body>): Send a notification with the subject <subject> and the text <Body> to <user name (user name)>. Notification types can include, but are not limited to, e-mail, calendar, fax, automatic calls, and other types of notification systems. The emergency notification may call the government agency (eg, “911” call) for the first responder's action, such as by police, traffic, commerce, military or other agencies.

  Schedule (<date / Time>, <action script>): This can schedule an action script to be executed at a specific date and time (ie, <date / Time> field). For example, a transaction can be started after a certain time or a notification can be set.

  Accept (<date>): The instance can be received against a policy and can be valid until a date that includes a date in the date field.

  Store (<value1>, <location1>, <value2>, <location2>,...): Value 1 can be stored in location 1, value 2 in location 2, etc. The location can be a database field, for example. Further, for example, it may be stored in a local storage device or a mutual or internal data store.

  PushPolicy (<policy description)>: This pushes the policy to this system or to another system. For example, satisfying a certain set of conditions changes the policy for RDS instance processing of other RDSs.

  CreateTransaction (<transaction type>, <recipient>, <field1>, <value1>,...): This can be similar to PushPolicy. Create transaction can send a transaction document to the recipient of the transaction type form. The data field for the transaction can place the value 1 in field 1.

  As those skilled in the art will appreciate in light of the disclosure herein, special scripts and other forms of programming languages are used in the present invention to enable more complex coding of criteria and rules. Can be used similarly. Such complexity additions may include loop structures including external to internal and internal to external loops, external special scripts, initial values, and access to external data including other complex conditional statements, etc. it can.

  Policy templates can provide suggestions, changes, modifications, or generally accepted work to enable data migration for use as an input to risk policy generation or risk policy. For example, policy data can take a number of forms, as will be apparent to those skilled in the art, and policy templates can allow migration from one form to another. The following is an exemplary description of a “trigger policy” policy template shown using XML.

  For example, in the exemplary “BuildingSecurity” document (see the XML-A and XML-B examples above), the Trigger Policy template first determines whether the Country value matches “Korea”. Can be checked. If there is a match, the policies GoldBuildingAsia and SilverBuilding can be tested against the document. If not, the policies GoldBuilding and SilverBuildingAsia can be tested against the document.

  Policy templates such as Trigger-Policy (trigger policy) can also create or embed other document instances. For example:

  In this example, a BuildingSecurity document can be converted to a new document KoreaBuildingForm. A new instance of the form KoreaBuildingForm can go through the trigger Policy. The mapping from BuildingSecurity to KoreaBuildingForm can be done in various ways as will be apparent to those skilled in the art. The mapping from tag value to tag value can be an exemplary method of information migration using a policy template. For example, a country value can exist in two forms, and policy template mapping can be done one-to-one.

As used herein, an instance of document 101 can be an approved instance or a denied instance. A document instance can be an approved document if the following two conditions are true:
(1) Accept () was executed.
(2) A request () is executed, and a member of the group designated in the request () approves the document.

The calculation 108 may show an example calculation of the risk category. The calculation method can be, for example, complex and entity-specific or non-generic entity-specific. For simplicity, in this example, exemplary operations may be of the following form:
F (g (Value), h (Value, Value ')) = Risk Cat value
Here, F is a mathematical sum of input values. In this embodiment, g and h can be various algebraic functions such as returning 50 when (value = true) and returning 100 otherwise. Similarly, multiple options can be generalized. For example, a calculation can return (value * constant), where the constant is a predefined integer. Thus, the values g and h can be or require one or more inputs, which are external, such as data inputs that respond to the question, or a calculation 108 on h. As in, it can be internal such as application of constants to acquired data.

  FIG. 2 is a flow diagram illustrating the application of multiple risk policies. In this illustrative example, document instance 202 for document 101 may represent an “entry form” for a particular input instance. The example document instance 202 is weighted 205 against one or more risk categories, where Risk Cat Value, y represents a value for document y in risk category y. As a result, for a particular exemplary risk policy 201, approve the document instance 202 to be approved via the Accept () function or the Request () function after the group's users have accepted or rejected the document instance. can do. A document instance 202 can be approved by more than one policy 203, 204 before final approval, such as in a hierarchy of risk policy application to a given document 101.

  In the exemplary embodiment of FIG. 2, risk policy 203 may indicate document instances accepted by only one policy, and risk policy 204 may indicate document instances approved by more than one policy.

  Note that in an XML-B embodiment, the RiskCat value can be document dependent and the same Document Instance cannot generate multiple RskCat values, such as values that can be associated with different policies, for example. I want to be. However, the same Document Instance can be evaluated with two different policies by assuming that the risk category has a different value under each policy. For example, a company may have an internal security policy and an external security policy. Such a policy requires that any sensitive digital data emanating from the organization be encrypted during transmission, whereas internally transmitted data need not be encrypted. Thus, the document can specify whether the data leaving the internal server is encrypted. Thus, for internal policies, the “confidentiality” risk category will generally not affect transmissions from an internal server to that internal server or to another internal server. However, an answer of “NO” regarding encryption for the document will affect the risk of the “confidentiality” risk category if the attempted transmission was an external transmission. Therefore, in the present embodiment, the score of the confidentiality risk category can obtain different results with different policies.

  This constraint in exemplary XML-B can simplify assessment by an inspector who can understand that a risk category has only one meaning. Such constraints on risk categories are merely exemplary and in some cases need not be used in the present invention. In such an exemplary approach, risk value evaluation may be limited to that specified in the policy rule. The risk policy reference can be incorporated into XML-B as follows.

  Document instances can be approved for policy. Similarly, policies and eligibility can be linked. FIG. 3 is a flowchart showing the relationship between policy and eligibility. A set of documents 305 can be associated with a policy or set of policies 301 via a relationship 306. Policies can be specified in a hierarchical nature. For example, “guard seal” (ie, the high level on the hierarchy) does not require a certain check on the shipment, and a check should be required for the low level of the hierarchy. Similarly, this can be done in eligibility. Obviously, if certain criteria are met as “goal seal”, the same approach can be taken to classify these assets during asset evaluation. Ship-transport means can be owned by companies that are themselves “infrastructure assets”. Of course, many exemplary assets have a “owned” relationship on the one hand and a “owned” relationship on the other. An asset can have a relationship that can be related to the risk assessment of any particular transaction. These relationships that are one-to-one, one-to-many, and / or many-to-many can be used for risk assessment. By way of illustration, a port can be evaluated in light of physical security. The relationship can indicate that some of the physical security for the port is “managed by” another entity. The entity “managed by” can also be evaluated, and its risk is appropriately included in the port risk.

  Eligibility 302 can be associated with one or more policy instances 301. For example, eligibility 1 302 and eligibility 2 can be obtained when document instance 101 or document instance set 305 is approved against policy 1. Eligibility may require more than one policy approval 304. In this example, the document instance needs to get approval for policy 2 and policy m to achieve eligibility 3. Thus, there may be a hierarchy between policy and eligibility. As described above with respect to the hierarchical nature of policies, eligibility can be hierarchical with respect to both other eligibility and policies as well. Eligibility can be coded in XML etc. as shown below.

  In the above example, the qualification “GoldSeal” can only be obtained if GoldPolicyPhysical and GoldPolicyProcesses can be achieved. However, if GoldPolicyPhysical or GoldPolicyPhysical is achieved, similarly, if you can achieve SilverPolicyProcesses or SilverPolicyPhysical, you will get “SilverSealS” if you can achieve both SilverSealS "Is not earned.

  FIG. 15 is a simplified illustration of FIG. As shown, a document instance can be associated with multiple input “documents” entered at different times. For example, document A (value below line 6002) can be received at time = 0 and stored in database 6004. At time = 1, document B (value above line 6002) can be received. Document A can be placed in document instance 6003.

  The policy evaluation described above can be part of a risk detection system (RDS). The RDS can exist in a large infrastructure as shown in FIG. The RDS can evaluate the policy against the document, maintain storage to evaluate the policy 507, and determine eligibility. The RDS can be linked to one or more aggregators 506. The aggregator can include an RDS that obtains information from multiple RDSs and provides policies and documents to other RDSs. If two documents appear in two RDSs, the aggregator can include a reconciler such as the internal global database 502. The aggregator can dynamically generate or apply policies based in part on history. For example, if multiple inputs to an aggregator from separate RDS instances indicate that they are overly exposed to country risk, the aggregator can modify various RDS policies to control the risk. . For example, if the acceptable threshold for country risk is reset to high, the revised document representing the transaction may not be accepted by the revision policy, and as a result, previously accepted document scores may not be accepted There is.

  The RDS and the aggregator can receive information from the internal global database and can obtain information from the mutual global database 502. A mutual global database can exist outside the organization. For example, customs organizations and border protection agencies, which are external organizations, may have “monitoring lists” of individuals and entities that are not recommended as business partners, and monitor lists that control handling requirements, etc. for specific classes of cargo. Have. The US Department of State maintains a list of known terrorists, and other government agencies and organizations, regulatory bodies and standards organizations, collaborators, and various other providers also maintain useful data for RDS. Some companies also provide statistical data and other data useful for dynamically and pre-generating policies. For this reason, information can be distributed to the system to establish a trust level.

  The trust manager 503 may represent a security trust system such as a public key infrastructure (PKI) [X500, X509, RFC3280] or Kerberos [Neuman] or means known in the art [Meneses]. Trust managers can be managed by mutual or internal regulatory organizations. A regulatory organization can be any individual or group that regulates what is authorized to communicate within the infrastructure and can regulate the authority that these authorized communicators have. The trust manager can make security extensible. However, the infrastructure of FIG. 5 may not require the use of a trust manager because security can be established directly using physical exchange of cryptographic keys or other methods known in the art.

  The entry point 501 can be a source that receives data. The RDS can receive data directly from the entry point or in combination with the entry point. The entry point can also be a probe in an intrusion detection system. Entry points can reduce costs by receiving data only and by placing data in the RDS, or a mutual or internal global database for the RDS or aggregator used. Entry points can be specialized and can be used to reduce workload from RDS.

  For example, the XML-B above can include policy enforcement, but the entry point can do some policy review of the document. This reduces the risk of outsiders identifying RDS policies. The entry point can also establish trust directly or via the trust manager 503.

  FIG. 6 is a flow diagram illustrating secure transmission of a policy template to a policy template, policy rule, or eligibility or document such as XML-A or XML-B. For example, template 605 can be transmitted 602. For example, the source can be an aggregator, RDS, or regulatory organization. The trust manager 604 can establish trust between the RDS and the source 603. As one example, if the trust manager is a PKI and the message sent by the source is signed, the RDS can verify the signature based on the certificate. The RDS, which can also be an aggregator, can receive a template that can be authenticated and can incorporate the policy template into subsequent evaluations.

  Policy templates can be generated by different organizations and components within the infrastructure. The priority, that is, the evaluation order can be specified as shown in FIG. In the above policy rule application embodiment, policies can be evaluated “top-down”. Policy 702 can also be configured by sub-policy. For example, policy 702 can be executed before policy 703. Some organizations can be placed higher so that government agencies can take precedence over business entities 703 or entities or individuals 704 formed in the region. Organizations can also specify priorities in their policy templates. Examples are shown below.

  In this example, government agencies can place multiple templates in the RDS, and these templates can be given higher priority than other sources 702.

  Access to the RDS can be granted to various organizations. Access control can limit access to information or modification of information based on who the user is and how the user is identified. FIG. 9 shows the user 905 accessing 906. User 905 can belong to a mutual regulatory organization or an internal regulatory organization 902. A trust relationship 903 represents a trust relationship between the trust manager 904 and the regulatory organization 902 and a trust relationship 907 between the trust manager 904 and the RDS 901. Trust can be added between the trust manager and the user through a mechanism developed for computer security. Such embodiments include a registration authority within the PKI acting as a surrogate for the regulatory body to verify the user, and a user public key authentication process. Based on the trust relationship established via trust manager 904, the user has specific access rights to the RDS and an aggregator or global database based on the rights provided to the user via some access control mechanism. You can have access to A government agent or collaborator can have limited or extended access, but internal users can have different access rights. For example, government representatives may receive data and data that are otherwise restricted, subject to the presentation of appropriate credentials, including the occurrence of defined events and the provision of online certification identities or roles. Certain access rights can be automatically granted to the store.

  An RDS can communicate with another RDS to provide policies, documents and / or eligibility instances or templates. RDS1 801 may send the object to RDS2 802 or global database data 806, 803, 804. Transmission 803 or 804 can be authenticated by digital signature or transmission over a secure tunnel, such as SSL, VPN, IPSEC or the like, or some other secure means known to those skilled in the art. Security can be used or established through a trust manager via trust relationship 805 to transmissions 803 and 804. Relationship 805 can represent a certification relationship, for example, by a trust manager operating as a certificate authority (CA) in a public key infrastructure (PKI).

  FIG. 8 represents a push technique in which the RDS sends out various instances and reports in a secure manner such as instances signed with a public key authenticated by a trust manager functioning as a CA. In practice, RDS does not require a push technique and can present information locally according to the pulled information. That is, RDS can provide a pull rather than a push. Accordingly, RDS applications 802, 806 can make requests and receive data 801 locally.

  Data presented externally by the RDS or other global data store, such as a global database, or a file, directory, or the like may be useful to the user. In FIG. 8, several types of information can be presented. For example, a report may be an audit log, aggregate risk impact, discovered anomalies, and other events indicating auditable conditions. Reporting allows external parties to review the procedures they are using, but can also require specific audit level access. Depending on the eligibility, template, policy template, or document template, the RDS can send the template for external review, or another RDS can implement this RDS.

The RDS can support various Roles. These Roles can include the following:
RDS Administrator: Basics not generally related to, but not limited to, user or identity management, providing access to groups and external components, monitoring system performance, confirming backup performance, and the risks being monitored by the system System basic management such as intelligent tasks is implemented.
Template creator: Creates various templates used in applications including policy, document, and eligibility templates.
Data entrant: Provides data to the system. There can be various categories of data entry persons with different privileges, for example, one person is allowed to fill out some forms but not other forms. Or only certain groups of forms are allowed to be filled.
Risk Manager: Specifies policy tolerances for risk categories and eligibility, how risk categories can be determined, and the actions that the policy performs on the various categories.
Document Approver: A document instance against the policy if a Request () action is set that requires the acceptance of the document for either each instance or some defined group of instances or instances Approve.
Supervisor approver: A special group of approvers. Some organizations may require approvers as well as document approval supervisors.
Auditor: Has read-only access to review the actions of others.

  A Role can be implemented at least in part by a computer system. For example, templates can also be created by RDS and aggregators, and data entry persons can be entry points. The risk manager can be a special type of template creator, for example, it can be an RDS or an aggregator. They can review past actions and determine policies for future actions.

  In the exemplary embodiment of the composite container shipping of the present invention, the defined categories can include infrastructure assets, shipping assets, shipments, and the like, and each defined category includes each of these categories. Can have documents and / or values that are expected to represent or represent this. The infrastructure asset can be a document about the infrastructure used to move the composite container between points, including from the loading point to the unloading point. Examples of infrastructure assets can be computer systems, information processing systems, warehouses, terminals in harbors, and the like. Infrastructure assets are not limited to physical entities or objects, but may be legal entities. For example, an enterprise that owns and / or manages a warehouse can be classified as an infrastructure asset. A transport asset may be a document that is an asset that is directly used for physical movement of a shipment, but may not be part of a shipment. For example, a train engine, container, or other ship or aircraft that is used for a specific purpose of shipment movement can be a transport asset. If it is difficult to determine whether an asset is an infrastructure asset or a transport asset, it can be treated as both. Shipments can be the goods that are actually shipped and the specific assets and documents that are used or associated with the movement of these goods. This category includes, but is not limited to, containers that are bound to physical shipments, seals that can indicate barriers or manual or electronic shipment modifications, and shipping instructions, bills of lading, and the like Documents related to a particular shipment, such as

Surveys, questionnaires, and / or other mechanisms can be used to identify other aspects of infrastructure assets, such as infrastructure assets and those who are responsible for the infrastructure assets. Infrastructure assets can have sub-parts, systems, or components. For example, a building can be an infrastructure asset. However, containment facilities located within a building but subject to different physical, logical, or legal regulations can be treated as sub-components of the building but may also be classified as infrastructure assets. . Infrastructure assets can be evaluated against various criteria, including but not limited to, based on the type of facility.
Physical security control (eg lock type, fence height, number of guards, etc.)
Control of personnel security (such as career checks, employment contracts, etc.)
Data system control (eg confidentiality, integrity, availability)
History control (eg history so far to determine whether fixed assets are being done properly)
Insurance (for example, insurance type and limit)
There is or may be an existing legal or regulatory action that has been initiated in the light of prior legal and / or regulatory actions on the asset (eg, assets, judgments, injunctions, verdicts, consent judgments, etc.) Have sex)
Contract control (eg contract terms for infrastructure assets, their workers, or plants)
Manufacturing supplier control (for example, its features, evaluation methods, etc.)
Record retention and audit control (eg, record retention method, type of audit control, etc.)
Procedures and implementation (eg task achievement methods)

  These criteria or their assembly or disassembly can be treated as a risk category. Additional risk categories can be included as needed. The nature of the asset being evaluated can determine the risk category used to evaluate it, as well as the selection and weighting of data values used to calculate the risk category value. Thus, the questions that make up the physical security risk category for warehouses with low values may be different from the questions that make up the same risk category for data centers with high values, for example.

  Assets can be entered in several ways for use by the RDS. This can be entered using a web system, or another application may notify the RDS of a new asset, for example. There may be a dedicated RDS for the input of one or more types of assets. As a result, these RDSs can provide data related to assets to other RDS systems. New assets may extend to another database, such as a manufacturer's database. Fixed asset information can come from, for example, an aggregator, another RDS, a mutual or internal data store, or other source. Information can also be obtained from, for example, fieldwork, surveys, government forms, or other data, whether internal or external.

  Once an asset is defined as a document, it can be evaluated based on an appropriate policy. The introduction of a new asset can be a trigger event, such as a new vendor transaction, web-based input, etc., which trigger event can result in evaluation against a trigger policy. This assessment can create multiple actions as part of the policy, for example: a) the assessment can be performed by performing a specific survey (eg, a physical building survey) and as a result appropriate people Notifications may need to be made to indicate that a new manufacturer has joined and the survey must be completed, and b) perform an external party assessment (eg, perform a site survey or other analysis) Can initiate internal and external data surveys (e.g., start a third party acquisition) (e.g. check list of denied parties, check for any legal / regulatory action, insurance policy, financial condition, Other validity assessment). When more detailed information is received, this information can be tested against that policy by the trigger policy. Upon receiving more detailed information, the policy can be met for some cases and asset eligibility can be gained in this filled case. In addition, asset eligibility (which may be the mode of transport, infrastructure, or shipment, as well as the shipment itself) is a prerequisite for the occurrence of other incidents such as the supply chain in which the shipment is booked; On a direct booking basis, or transport of shipments by a carrier upon receipt from, for example, a multi-modal general carrier; freight pricing; promised shipping date; goods transport or other goods used to transport, handle, pack, store It can be insurance compensation for assets.

  Policy-based approval can be as short as eligibility. For example, short-term approval can be provided when material is present but there is no significant hindrance to expected control or no expected control. For example, a building's physical security policy may change. Buildings that meet certain confidentiality criteria can only receive locks accepted by previous physical security policies for up to a month. After one month, the short-term approval is no longer valid.

  Approved shipments are in document form, the goods in transit, their packaging, composite containers that can contain and transport goods, and various security, visibility, or status devices for the containers of goods, And shipping related documents or messages (bills or advance shipping notices). Shipments can be part of a particular shipment, particularly those that are evaluated in the risk management assessment of the containers therein.

  As those skilled in the art will appreciate in light of the teachings herein, the risk profile of a particular container, among other things, is the facility and transportation in which the container is packed, stored, moved together, or passed. The location and owner; the history of any person accessing the container or goods packed everywhere along the path; the policies, procedures, and practices implemented to prevent or detect unauthorized additions or deletions to the cargo; It can be affected by several factors, such as practices; or tamper evidence data obtained directly from containers during transport. Data related to the above factors can be maintained by several different entities, all of which are either allowed for containers to be loaded into container ships, delivered to ports, or governmental It can be important to determine if it should be released from storage.

  Furthermore, it may not be sufficient to determine aggregate risk by analyzing the risk profile of a single container. For example, it is desirable to divide shipments that cause an attack into multiple containers, each of which appears to be harmless individually, but terrorism that terrorists may have sufficient knowledge to pose a threat when combined The relationship between multiple containers and other factors may be required to determine the overall risk of a non-event.

  Efforts to implement joint risk management in the supply chain context can be complicated because some members of a single supply chain may compete with each other. For example, this is incorporated into a maritime business model where carriers, NVOCCs, consolidators, and others reserve container transfers with carriers on a spot basis or according to a shipping contract. The booking entity may wish to hold information from the shipping entity, especially customer data, so that the carrier does not bypass the reservation entity and try to contact the customer directly. is there.

Risk and risk information repositories and approaches areas can include:
All or one of the various aspects (eg, physical, logical, financial, etc.) of infrastructure or transportation assets (including accountability programs for all supply chain phases that address workers and corporate assets) The department's risk posture can be used to collect, manufacture, pack, load, enclose, move, etc. the shipment.
Screening mutual or internal data stores for relevant information about infrastructure materials, their ownership, or other material “related” to relationships that may affect risk.
Conditions under which containers can be loaded and sealed, including various types of inspection, loading and documentation procedures, use of independent inspection agencies, physical access control, logical protection, etc.
Positive and negative rule sets for containers related to shipping duration, weight, time, location, condition, etc., as well as other related risk management rules and exception procedures, among other possible parameters. For example:
It is not longer than a certain period.
It is not shorter than a certain period.
It is not farther than a specific measurement distance.
At least a specific measurement distance range.
Fluctuation from the expected route regardless of land or sea.
Forbidden location including determination by GPS tracking.
Expected location including determination by GPS tracking.
Document anomalies such as inappropriate starting point or destination based on origin or season,
Open or small volume rules for sensors or seals,
Unexpected nuclear, biological, or chemical substances,
Unexpected temperature changes,
Unexpected gas content such as CO2,
Analysis of shipping or container related status message anomalies that may already be offered to supply chain subscribers,
Analysis of abnormalities in shipping related documents (other than status messages).

  Note that the various incident histories and signature templates and reporting functions can be independent services in the present invention. That is, it may be useful to recognize that some aspects of the system are approved by some approval authority or person. As one example, a manufacturer can be approved by an institution against a policy. This approval can be incorporated into the RDS. The authorization incident can be signed or have other security controls placed on it. Companies can purchase approval incidents that the regulatory body sells approvals as self-funded sources, or can allow third parties to sell approval incidents or some aspect thereof.

  As shown in FIG. 10, in a specific exemplary description of risk management in a joint transportation environment, a document having values therein is provided. This value can be scored according to one or more risk policies, which can be present in one or more risk policy templates as described above. Risk analysis can be performed according to multiple scoring mechanisms. For example, a financial institution can score a document and its value in one way, and an insurance organization can score the same document and the value in another way.

  In such an exemplary embodiment, global supply chain risk can be assessed. For example, a warehouse in the supply chain can contain a large number of documents having multiple values. These documents can be classified into categories according to the risks for the documents. For example, warehouse security can form one category and the power supply can be another category. Risk can be analyzed against a risk policy based on the value. For example, a warehouse security document may include the value “Camera presence: YES”. Obviously, such a value will have a substantial impact on whether security is successful or has reached a certain eligibility based on the application of the policy to warehouse security and the application of the risk policy to such value. There is a possibility of effect.

  In addition, one or more associations can be provided as values that can affect risk. Associations available for relationships that can affect risk include, for example, Ownedby, Lesser of, Lesse of, Lesser of Customer, Vendorof, Supplier of, Managed by, Managed by, Regulated by, Insured, Audited by, Evaluated by, Inspected by Inspector), Auditedby (audited person), Operated by (operated person), Process for (process), Financial institution for (financial institution), Insurer of (insurer), Includes urantor of (guarantor), Security for (collateral), Relatedto (if association or association type is not specified in the system), and the reverse (eg, the reverse of the owner is the owner) be able to.

  Thus, this exemplary link in the supply chain can be scored for each category and the entire category according to the values in the document. The risk analysis and the overall risk analysis can follow one or more templates. For example, if there is a warehouse in a first country where the crime rate is high, the overall score 80 or the security score 85 cannot be allowed. However, if there is a warehouse in a second country with a low crime rate, the overall score 70 or the security score 75 can be considered acceptable.

  As seen in FIG. 10, system 1000 includes a central node 1001, at least one auxiliary central node 1002, at least one first tier enterprise 1003 communicatively coupled via an aggregation node 1005, and at least one. One second tier enterprise 1004 as well as at least one last resort aggregation node 1006. The government is illustrated as well and will be described in detail below.

  The system 1000 is a collection of all nodes that can be bound by some type of agreement, such as a contract network, and share risk-related data present in documents according to rules governing the system 1000. . The rules of the system 1000 can be based on document definition relationships such as contract relationships that define at least one or more operational procedures, risk standards, and response protocols.

  The central node 1001 can be the highest level entity within the system 1000. The central node 1001 may be responsible for, among other things, distributing risk policies or permitting distribution to all nodes within the area of the central node 1001. The central node 1001 can further function as a last resort information aggregator for commercial security purposes.

  The central node 1001 can consist of a single entity as shown in FIG. 10 or can be a group of entities that work together through some known mechanism or agreement. The central node 1001 can be connected to another auxiliary central node 1002 that performs certain functions, such as decisions regarding insurance or other special or subject expertise. The central node 1001 can also be defined for well-defined functions or roles within the system. For example, an insurance company can define a central node CN1 to guarantee its policyholder, the central node CN2 can be for another policy, and the central node 3 Member control can be specified and monitored, for example, to an industrial organization that obtains favorable regulation handling. Furthermore, CN1, CN2, and CN3 can function within the global CN-GLOBAL that covers all entities. As another non-limiting example, the central node 1001 serves as a self-monitoring in the system and whether certain parts of the system 1000 have been compromised or have improperly modified state. And respond with an appropriate action. For simplicity and ease of understanding, the invention has been described using a single central node 1001, but it will be understood that any number or combination of central nodes working together may be used. I want.

  Entities' participation in the system 1000 may or may not be hierarchical where members at different stages have different requirements or rights. Although FIG. 10 shows a hierarchical environment, it will be apparent to those skilled in the art that a single hierarchy can be used. In an embodiment of the present invention that uses a tiered environment, a lower layer business entity may allow one or more higher business entities in the chain to join according to the rules specified by the central node 1001. According to aspects of the present invention, there can be two tiers 1003 and 1004, one consisting of a large enterprise with highly automated operations, and the second tier being the first on an outsourcing basis. It consists of small businesses that use other technologies, including layered businesses 1003. For example, according to aspects of the present invention, the primary carrier can belong to the first tier 1003. A small business that obtains reservation or tracking and tracking functions from a major carrier may be a second tier business 1004. Any number of layers can be used, as will be apparent to those skilled in the art. The central node 1001 can be responsible for identifying the appropriate characteristics of members at every layer.

  As part of this function, the central node 1001 can define one or more sets of data elements, which are used to document the information set, preferably the entire set, for risk management. Need to form. For example, for cargo, the aggregation node 1005 can be responsible for aggregating risk-related information across the entire population of subscribers involved in a particular shipment. The aggregation node 1005 may be any entity of the system 1000 that aggregates risk-related information from at least one entity other than itself. Participants in the system 1000 can challenge a particular aggregation node on the basis of commercial secrets or other similar reasons. When an objection arises that can be recorded or understood in many ways that will be apparent to those skilled in the art, the aggregation node 1005 for that information may in some cases function as a neutral aggregation node with the central node 1001 being the final means 1006. Up to the system defined in the system rules.

  Referring now to FIG. 11, a graphical representation of standard creation and implementation of the system of FIG. 10 is shown. As can be seen in FIG. 11, the system 1000 is a global standard established by at least one standards organization 2001 (eg, can include a government), an interaction of at least one standards organization 2001 and the central node 1001. It may further include a set of standards 2002 and processes and procedures 2003 formulated according to system rules.

  Standards promulgated by the central node 1001 are non-governmental organizations, insurers, financial operators that undertake drafting supply chain related risks or security rules in relation to central governments, governments or other parties concerned about border policy And other stakeholders in the system may be acceptable, such as others that may be required to assume security obligations or risk transfer within the supply chain. The central node 1001 can be responsible for adopting policies and standards for the system 1000 promulgated through system rules. The central node 1001 can negotiate with standards stakeholder to obtain a globally accepted set of standards 2002.

  The central node 1001 can further be responsible for developing processes and procedures 2003 that allow entities to enter the system 1000 through bilateral execution of documents in the form of contracts that bind each entity to system rules. The system 1000 can contemplate criteria for eligibility within the system 1000, which can be developed by an external entity such as the central node 1001 and members, standards organization 2001, or government regulators.

  Referring now to FIG. 12, there is shown a diagram of confidentiality, compliance, aggregation, and payment according to aspects of the present invention and the system of FIG. In an embodiment of the present invention, the NVOCC may allow a booking entity to hire the NVOCC, which may, for example, place an order to reserve a container for a particular container or other cargo route to the United States. It can be an entity in the international trade transactions it receives. In this role, the NVOCC may have certain customer information that it is desirable not to provide to the shipping entity 3001, which is the entity that operates the cargo transportation device. The shipping entity 3001 may need to screen the customer name against a list of denied parties before agreeing to container shipping. The shipping entity 3001 may also be responsible for submitting customer identities through the electronic interface 3007 to government authorities 2001, such as, for example, US Customs and Border Protection. Such a prior notification system 3002 can be created to follow US 24 hour prior notification rules, or other similar rules known to those skilled in the art. In the system 1000, if the booking and tracking entity is not the same as the freight entity 3001, the freight entity 3001 has a document with data that specifies a value proving compliance with the security requirements by the reservation and tracking entity. May be required, or it may be required to be based on a representation 3003 that is supported by a legal entity in which the corresponding entity is in compliance. Alternatively, the central node 1001 can also create the representation 3004 via one or more documents having values for the relying entities. The central node 1001 can define an instance where the central node 1001 is the only entity that can create a particular representation, or representation class, or a combination thereof.

  Various entities within the infrastructure can be intended to make risk or security related expressions publicly or towards others in the system. The system 1001 can provide such a representation on a system scale 3005 or on a peer-to-peer base 3006 to charge or be charged for these representations.

  Similarly, although not necessarily identity information, a key escrow mechanism may be introduced to hide information in the transportation entity 3001. The identity and other information can be encrypted, for example, so that the government entity 2001 can decrypt it to determine the original form. Key escrow techniques developed in the fields of cryptography and data security include threshold schemes, secret sharing, and other techniques. The central node 1001 can establish rules, processes, and mechanisms that enforce escrow as needed. In some cases, entities within the system may be required to electronically prove that the entity has operated the escrow in an appropriate manner, such as by cryptographic and data security certification mechanisms. Alternatively, certain information may be protected using a pseudonym.

  Entities that query the system may need to hide the query request. For example, a police officer working in a global system may want to keep inquiries confidential. The use of private information retrieval technology can be used for concealing recorded queries. In addition, the requesting entity can be concealed using, for example, protection techniques such as onion routing known in the cryptography and data security fields.

  Aggregation node 1005 can be a decision node, i.e., a point at which a risk-related decision regarding a document is to be made. The decision making node is in the system 1000 that decides whether or not it is possible to proceed with the transaction in the normal manner with respect to risk-related information received from the system 1000, system subscribers or others. Can be a business entity. For example, the shipping entity 3001 can decide whether to agree to the carriage of a particular container or the conditions that would agree to the carriage of such a container. Decision nodes can include, among other things, a central node 1001, an overseas logistics company, an importer, a consignor, a customs broker, an insurer, a financial institution, a government agency, or a terminal, as non-limiting examples only.

  Referring now to FIG. 13, there is shown the risk transfer, information aggregation, and credit infrastructure of the system according to FIG. 10, according to aspects of the present invention. The decision making node can decide whether to transport the container based on the received risk-related information or the responsibility burden expression, or whether to set the transportation condition. The central node 1001 may decide to recommend the containers 4001 and 4002 for a certain type of insurance coverage based on the received information and liability representation. Similarly, an insurance entity determines whether to provide compensation for a particular container, cargo, or shipment based on aggregated information received through the system 1000 or a liability representation for certain information status received. can do. Which decision-making node decides to carry is determined by several possible aspects including, but not limited to, container territory, insurer, home port, destination port, and cargo type Can do. In decision making, a decision node relies on either information to be received and analyzed and / or a responsibility expression for which a certain security or risk compliance status has been achieved for a particular shipment, container, or shipment. Can do. The analysis of the document is broad in the coarse risk assessment of a single container 4003 based on other information about the container or other documents such as shipments obtained by referring to the actuality around the system 1000 or other shipments. A visual field can be secured. The falseness of the expression that should be correct can depend on the disclaimer of any responsibility by any entity that has decided to accept the risk based on that expression, as well as the basis for the return request to the node that generated the false expression. System rules can also provide that certain reserves or collateral are provided by member entities to prevent false expressions.

  Decision making can be real-time, but can allow "reversal" or "mitigation action" after the decision is made. That is, a decision can be made to allow the progress of the supply chain process such as loading of the container onto the ship, but at the time the decision of “permission” is made, the information is unknown, and the document So, with subsequent information that represents a greater risk than the container previously thought, reversal or mitigation can be performed. If the shipment was in transit in this example, reversal may not be possible or practical, unloading at the nearest port, or crew or other risks and security while on board Other mitigation actions can be initiated, such as inspection by an expert. By way of illustration, after a container is loaded, when the ship is in transit, it will be found through the newly developed intelligence that the entity that loaded the container is involved in the terrorist organization. As a result, despite any previous “permission” or “loading” decisions, re-evaluate past decisions, make new decisions based on current insights into risk, and generate new data. Based on this, it may be necessary to initiate a reversal or mitigation action.

  Compliance with security policies implemented within system rules can associate a container with a certain insurance coverage designation, or make a container eligible for that designation. For example, rule compliance can be a prerequisite for obtaining liability insurance for a container, or it can be a prerequisite for waiving terrorism or nuclear exclusion and otherwise ensuring that such a warranty applies. .

  Data passed between system nodes can be protected against interception or tampering, and the person or system authorized at this node must receive an appropriate level of authentication. By way of non-limiting illustration, the system 1000 can support the use of computer security techniques such as, but not limited to, encryption, access control mechanisms, error correction protocols, etc. to achieve these objectives. In accordance with aspects of the present invention, each person, device, or process within the present invention can issue a cryptographic token or other material after their appropriate identity verification 4003. This token or material can authenticate 4003 a person, device, or process if presented correctly. Cryptographic techniques known to those skilled in the art can be used to ensure that the data has not been altered without permission or has not been corrupted in an unknown manner. If the authentication technology involves the use of public key encryption technology, the public key is kept in the central directory, not distributed in the certificate, and public keys linked to authorization and other relevant data are in the directory. Can be held.

  Referring now to FIG. 14, a specific embodiment of the system of FIG. 10 is shown. The system 5000 can include a central node 5001, which is a security policy associated with documents representing cargo in international trade, and system rules for managing the actions of all actors in the system 5000. Distribute a set of The central node 5001 serves as an information security device between commercial entities to protect competing information. The ability for any node to act as an information security device for other nodes can be defined in system rules. The set of nodes, including the central node 5001, can receive an expression regarding the security state, can receive permission on behalf of the representative party, and pass the expression to a transient trusting party. This gives you the ability to set policies between nodes based on system scale, bipartite, or multiparty, and solves the risk of contracting partners within acceptable limits in accepting or taking action on this value . Allow the system to communicate on a peer-to-peer basis to present a payment request or request or payment mechanism for certain information supplies, which can be used as an information pricing mechanism . The authentication and security infrastructure to prevent and detect unauthorized persons, entities, devices and processes from participating in the system and further ensure data integrity is provided by the central node 5001 or the central node. 5001 can be managed.

  The shipping entity 5002 can create routes and status and can provide facilities to facilitate shipping. The shipping entity 5002 can provide route information for a 24-hour rule application, can be a primary party facility security status, and can monitor containers in transit.

  The tracking entity 5003 may be an entity that is responsible for receiving data regarding documents such as cargo when the cargo leaves the freight station. The tracking entity 5003 can provide data in transit collected by special screening, can provide data on the content of items related to documents such as containers in the form of values, such content information Can include, by way of non-limiting illustration, internal sensor readout information, cargo location, navigation period, and number of miles traveled. The tracking entity 5003 can include information regarding intermediate destinations.

  Additionally or alternatively, other information can be monitored by using the present invention, at least by values in the document tracked by the system 1000 of the present invention. For example, a transaction can be security-scored by an independent transaction part or the entire transaction. For example, scoring can include purchase orders, invoice delivery, or container storage. Similarly, scoring can be directed to any business process including, for example, manual, electronic, or a mixture of both, and can be all or a selected part of any document or flow. Reports can be made available to any part or all of the application of the present invention. For example, the report can be electronic or paper.

  One skilled in the art can implement the invention using readily available hardware and software techniques in accordance with the teachings set forth herein and the citations referenced herein and incorporated into this disclosure. it can. Further, any of a variety of computing aspects, languages, or scripts, including XML, can be incorporated into the present invention.

  Those skilled in the art will appreciate that many modifications and variations of the present invention can be implemented without departing from the spirit or scope of the invention. Accordingly, the present invention is intended to protect the modifications and variations of this invention provided they come within the scope of the appended claims and their equivalents.

It is a figure showing the mapping between a document, a risk category, and a policy. It is a figure showing the some risk policy with respect to several document instances. FIG. 4 is a diagram representing a relationship between documents, policies, and eligibility. It is a figure showing acquisition by the document instance of the value from the database for incorporating in a field (value). It is a figure showing the component of RDS. FIG. 6 is a diagram illustrating secure transmission of a template. FIG. 6 is a diagram representing policy enforcement from different organizations. FIG. 4 represents secure transmission of an instance or template from an RDS. FIG. 6 is a diagram representing user access associated with a trust manager. It is a figure display of the role (role), flow, and organization of the present invention. FIG. 11 is a diagrammatic representation of standard creation and implementation of the system of FIG. FIG. 11 illustrates privacy, compliance, aggregation, and payment representation according to aspects of the present invention of the system of FIG. FIG. 11 illustrates risk transfer, information aggregation, and credit infrastructure of the system of FIG. 10 in accordance with aspects of the present invention. FIG. 11 illustrates a specific embodiment of the system of FIG. FIG. 5 is a diagram showing a combination of a plurality of documents using the method of FIG. 4.

Explanation of symbols

101 Document 102 Risk category 104 Value 105 One-to-many correspondence 106 One-to-one correspondence 107 Risk policy 108 Calculation 109 Many-to-one correspondence

Claims (53)

A system for managing risk associated with at least one business process,
A first node forming at least part of a plurality of communicable connection nodes for collecting at least one risk-related data value associated with at least one document;
Communicatively coupled to the first node, receiving the at least one risk-related data value, and transferring the at least one document related to the at least one risk-related value according to the at least one risk-related value to a plurality of risks A second node of the plurality of communicable connection nodes that evaluates against at least one of the categories;
With
The second node implements the at least one risk category according to at least one risk policy approved by a central node of the plurality of communicable connection nodes for the at least one business process;
The second node determines whether there is a risk for the at least one document according to a rating score for the at least one document according to the at least one risk category.   The system of claim 1, wherein the risk is associated with an infrastructure.   The system of claim 1, wherein the at least one document is a cargo container.   The system of claim 1, wherein the evaluation by the second node includes an intervention sought by at least one member of a group specified in the at least one risk policy.   The system of claim 4, wherein the implementation includes at least one notification to the at least one member.   The system of claim 1, wherein the determination allows the at least one document to enter the business process.   The system of claim 1, wherein the at least one document includes survey results.   The system of claim 1, wherein the at least one document includes a superset of a second plurality of documents.   The system of claim 1, wherein the at least one risk policy is hierarchical.   The system of claim 1, wherein the at least one risk policy has at least one qualification associated therewith.   The system of claim 10, wherein the at least one eligibility is hierarchical.   The system of claim 1, wherein the at least one document describes at least one asset in the at least one business process.   The evaluation by the second node includes physical security control, personnel security control, data system control, history control, insurance, asset action, contract control, manufacturer control, record keeping, and audit control. 13. The system of claim 12, including an evaluation for at least one of the group.   The system of claim 13, wherein the audit control includes authorization.   The system of claim 13, wherein the audit control includes a rejection.   The system of claim 13, wherein the audit control includes physical storage.   The system of claim 1, wherein the determination by the second node does not permit use of the at least one document in the at least one business process.   The system of claim 1, wherein the second node sets at least one of the at least one risk policy for the at least one business process.   The system of claim 1, wherein the at least one policy at least partially manages an interaction with at least one of the plurality of communicable connection nodes.   The system of claim 1, wherein the at least one policy at least partially manages a risk determination method of the second node.   The system of claim 1, wherein the data transfer is managed at least in part by at least one contractual relationship.   The system of claim 1, wherein the data transfer is managed at least in part by at least one set of enforceable rules.   The system of claim 1, wherein the data transfer is managed at least in part by at least one set of enforceable standards.   The system of claim 1, further comprising security suitable for business entity authentication.   The system of claim 1 further comprising security suitable for ensuring data integrity.   The system of claim 1, wherein the determination by the second node indicates an acceptable risk associated with a document.   27. The system of claim 26, wherein the determination by the second node is preparation for insurance or obtaining a loan for the product associated with the document.   The system of claim 1, wherein the plurality of communicable connection nodes comprises a computerized network. A method for managing risks associated with at least one business process comprising:
Collecting at least one risk-related data value associated with at least one document;
Evaluating the at least one document related to the at least one risk-related data value against at least one of a plurality of risk categories;
Implementing the at least one risk category for the at least one business process according to at least one risk policy approved by a central node of a plurality of communicable connection nodes;
Determining whether a risk of the at least one document exists according to a rating score of the at least one document according to the at least one risk category;
Including methods.   30. The method of claim 29, further comprising qualifying at least one of the at least one document according to an approval rating of the at least one document in at least one risk category.   30. The method of claim 29, further comprising disqualifying at least one of the at least one document according to a rejection rating of the at least one document in at least one risk category.   30. The system of claim 29, wherein the risk is associated with an infrastructure.   30. The system of claim 29, wherein the at least one document is a cargo container.   30. The system of claim 29, wherein the evaluating step includes seeking intervention by at least one member of a group specified in the at least one risk policy.   The system of claim 34, wherein the implementing step includes notifying the at least one member.   30. The system of claim 29, wherein the determining step allows the at least one document to enter the business process.   30. The system of claim 29, wherein the at least one document includes survey results.   30. The system of claim 29, wherein the at least one document includes a superset of a second plurality of documents.   30. The system of claim 29, wherein the at least one risk policy can be hierarchical.   The system of claim 10, wherein the qualifying step can be hierarchical.   30. The system of claim 29, wherein the at least one document describes at least one asset in the at least one business process.   The evaluation stage includes physical security control, personnel security control, data system control, history control, insurance, asset action, contract control, manufacturer control, record keeping, and audit control. 42. The system of claim 41, comprising evaluating at least one.   43. The system of claim 42, wherein the audit control includes authorization.   The system of claim 42, wherein the audit control includes a rejection.   43. The system of claim 42, wherein the audit control includes physical storage.   30. The system of claim 29, wherein the determining step does not allow use of the at least one document in the at least one business process.   30. The system of claim 29, further comprising setting at least one of the at least one risk policy for the at least one business process.   30. The system of claim 29, wherein the at least one policy at least partially manages an interaction with at least one of the plurality of communicable connection nodes.   30. The system of claim 29, further comprising ensuring authentication of at least one entity.   30. The system of claim 29, further comprising ensuring the data integrity.   30. The system of claim 29, wherein the determining step indicates an acceptable risk associated with the document.   52. The system of claim 51, wherein the determining step is preparation for obtaining insurance or financing for the product associated with the document.   30. The system of claim 29, wherein the plurality of communicable connection nodes comprises a computerized network.

Images