The present invention relates to an event management system for organizing and managing an event by using a computer network.
When events are held such as traveling in parties, a group tour, a publication party, a meeting for exchanging congratulatory greetings, a meeting for exchanging business cards, a birthday party, an offline meeting, a quiz competition, a music concert, a live concert, a stamp rally, an orienteering, and a wedding reception, participants have a desire to search for personal information that is statistically highly correlated with personal information such as their own hobbies and preferences. Further, in many cases, the search operation is performed using mobile terminal equipment such as a mobile phone or a smartphone having a relatively small screen. Therefore, it is devised to enable an efficient search even with a small display screen. Patent Literature 1 discloses an information provision system that enables such a search.
In addition, an event management system and a method are desired in which both an organizer and participants of an event are registered as members, the event is held smoothly, and the organizer and the participants can be appropriately managed. Patent Literature 2 discloses, in order to deal with such a problem, an event management system that includes a member terminal and an event management server, and manages progress of an event on the event management server side. The event management server includes member information storage means, event holding/participation condition information receiving means, extraction means to extract members who can participate, event holding notification means, participation application receiving means, participation point granting means, questionnaire implementation means, and questionnaire point granting means. The member terminal has event holding information receiving means, event participation application transmitting means, and questionnaire response means.
Furthermore, since it is difficult to use an event management program that runs on an event management server for other events, cost-effectiveness of holding an event cannot be obtained as expected. A system design for enabling additional functions of a user terminal, such as a barcode reader, a moving image capturing function, and an infrared transmission/reception function, is complicated and time-consuming. Patent Literature 3 proposes, in order to deal with such a problem, constructing of a basic function of a server in event management and operation as an application program interface (API). Examples are a communication function API, a participant information management API, a scene node management API (API for each scene generation of an event, API for scene execution, and the like), a market API for buying and selling a commodity, an advertisement distribution API, an interface corresponding to a participant terminal accessory equipment, and the like.
Further, in Patent Literature 3, there is provided a function of accumulating participant attribute information and action information as a life log, and using this to promote communication between participants, in order to increase motivation of participants by using attribute information of the participants obtained through the event.
Patent Literature 4 discloses an event management system including event plan preparation management means that constructs an event plan or event plan components with a structured document and combines them to prepare an executable event plan, and event implementing means that controls progress of an event by distributing messages to and receiving responses from participant terminals.
Patent Literature 1: JP 5158302 B2
Patent Literature 2: JP 5072003 B2
Patent Literature 3: JP 5182854 B2
Patent Literature 4: JP 2009-176269 A
However, a simpler user interface has been desired from those who create an event and participate in an event. Whereas, a system is required to be structured in accordance with a structured document such as HTML.
The present invention has been made in view of the above circumstances, and it is an object of the present invention to provide an event management system that allows a user to easily create and participate in an event and that can realize an excellent program as an analysis structure.
As a result of diligent research in view of the above technical problem, the present inventor has conceived that the problem can be solved by treating a module of a program as a nested scenario. That is, the present invention is to provide an event management system that uses scenarios, zones, transition arrows, icons, descriptors, and the like to realize advanced programming while maintaining a graphical user interface, and that is also excellent as a structure by interpretation and analysis processing.
An event management system of the present invention is an event management system including: an API database that stores, an event execution management API that performs execution management of at least one or more of execution of a scenario that is a constituent unit of an event, transmission and reception of a message with an event participant terminal, position information processing of an event participant terminal, event progress recording, log data collection, or advertisement distribution, and a resource management API that identifies and manages each physical resource including at least one or more of a terminal that is an operation target by the event execution management API, equipment, a commodity, a building, a place, transportation means, or communication means; an event database that stores an event execution program and log data generated during execution of the event; an API registration processing unit that receives an API conforming to a predetermined API definition specification from an API provider terminal and registers in the API database; an event generation processing unit that transmits, to an event creator terminal, a predetermined event definition specification and an API freely selected from APIs stored in the API database, and receives an event execution program that is generated with, as a component, an API received in accordance with the predetermined event definition specification in the event creator terminal; an event registration processing unit that registers, in the event database, an event execution program conforming to a predetermined criterion of feasibility in the event management system and a validity criterion of an event freely set by a manager, from among the generated event execution programs; and a communication processing unit that transmits and receives information necessary for event execution or related to event execution between with an event participant terminal through a network.
A module of the event execution program is treated as a nested scenario, and the event creator graphically describes an operation of an object layered by a module in a scenario chart attached to each module, an object called a zone including a time zone and a field zone is used as the object, an icon and a descriptor for graphical description of the scenario chart are used, the event management system further includes a chart diagram interpretation unit, and the chart diagram interpretation unit interprets an inclusion relationship of contents and the descriptor with respect to the time zone, in a completed chart diagram.
As a result, chart interpretation equivalent to programming in a markup language is realized. This makes it possible to provide an event management system having a structure conforming to a structured document such as HTML, while making a user interface easy to understand at a time of scenario creation and scenario participation.
Here, the icon and descriptor for graphical description of the scenario chart can include a transition arrow. Embodiments that do not include transition arrows are also possible. In that case, the above functions can also be realized graphically through arrangement of objects in an adapter, by dividing a chart screen into object adapters instead of transition arrows regarding arrangement of the objects, or adding an additional description form or a small screen, to give an inclusion relationship of zones or connection relationship information of transition arrows, to a relationship between the adapters or an adjacency relationship of objects.
Specifically, the following can be considered as an embodiment that does not include a transition arrow (see
In a chart, a top-level time zone or field zone is allocated to one or more columns. The columns are divided into an object allocation area and a lower-level column allocation area. In the lower-level column allocation area, it is possible to further allocate and divide a zone of a same type that has a relationship of being included. In the object allocation area, object adapters are arranged, and objects can be arranged. By controlling, for individual objects, a positional relationship in the allocation area (a sequence arrangement order and an adjacency relationship) or an implementation order, and arranging a descriptor object that describes transition information and an object addition marker at appropriate positions, interpretation structured by zones similar to those by transition arrows and zones is performed. In addition, this screen can be display-controlled for each column for easy viewing. For this display control, a sub-screen or a window may be opened.
Further, as information to be interpreted by the chart diagram interpretation unit may include, in addition to “the inclusion relationship of contents and the descriptor with respect to the time zone”, a structure of the time zone, field zone information arranged in the chart, portion arrangement information of contents and the descriptor on other icons, and a connection relationship (the icon and the icon portion).
Furthermore, the event management system further includes an analysis structure generation unit.
The analysis structure generation unit, in accordance with information interpreted by the chart diagram interpretation unit, analyzes a nested relationship of the time zone or the field zone to structure a plain field as a top-level time zone or a top-level field zone together with property information, adds, as reference information, a field zone in a case where a top level is the time zone, and a time zone in a case where a top level is the field zone, lists contents and a descriptor included in each of the time zones as elements at a corresponding position in a structure together with property information, adds the icon subjected to portion arrangement, as a child element of each element (property), and adds transition information as a property and instruction information from both directions.
As a result, an analysis structure is generated and set as a structure unique to a chart, that is, a module, and chart interpretation equivalent to programming in a markup language is realized.
This makes it possible to provide an event management system having a structure conforming to a structured document such as HTML, while making a user interface easy to understand at a time of scenario creation and scenario participation.
Note that “adds, as reference information, a field zone in a case where a top level is the time zone, and a time zone in a case where a top level is the field zone”
There is further provided a log analyzing unit and a log generation unit that generates a participation log of a participant of the event as a log structured with time and a location classified with a context for the event, in a form of corresponding to the generated analysis structure and inheriting a structure of the generated analysis structure, the log generation unit generates, as a log, zone and module passage information and service usage information of a participant, and the log analysis unit can aggregate passage information of all participants to analyze importance of a specific node and analyze related information between with a transition destination and a transition source, or analyze an action of a specific participant from contents information of a node or context information given to a node of a manager, to extract an action characteristic and preference of a participant. This enables utilization of big data or manage specific participants.
The passage information has a correspondence with the original structure.
There is further provided an event monitor unit and an emergency response unit corresponding to the above structuring.
The event monitor unit grasps event participant passing information for each node collectively (statistically) for each context in real time in an event monitor (see the relevant section), or detects an occurrence of emergency, and the emergency response unit can control progress of an event for responding to emergency in each node. This allows real-time event management for each node.
A log structured with time and a location classified in the context of the event is easy to analyze and manage participants in the event, and can be effectively used in big data.
Furthermore, there is further provided a user check unit, and an event participant generates and selects a two-dimensional barcode page corresponding to a node through which the event participant is passing. This enables announcement of an own situation to a manager and other users in a form that can be handled by the manager and other user.
By providing the user check unit (2-11, 2-12), in event management, it is possible to grasp the event participant passing information for each node collectively for each context in real time in an event monitor (see the relevant section), or to detect an occurrence of emergency. Therefore, the progress of the event can be controlled by a manager trigger or an emergency response means of the event monitor.
In addition, by generating and selecting the two-dimensional barcode page corresponding to a node the participant is passing through in 2-11, the participant can announce the manager and another user about an own situation in a form that can be handled by the system categorized by User check 2-12.
There are a plurality of the event creators, and they are treated as manager users, and a general user who uses an event and a manager user who creates an event are treated with discrimination, the event management system further includes a point management unit that manages a point and a title that are profits given by a manager user to a general user, and the point management unit can carry over a point and a title set by a manager user at a time of using an individual event to an event created by another manager.
This enables points and titles to be shared in a situation where a plurality of events and a plurality of event creators are mixed.
The event generation processing unit dynamically create and execute event scenarios on the user terminal by enabling a manager user to interact with a graphical user interface (GUI), which allows the manager user to visually construct event scenarios through manipulation of graphical elements that represent event modules, each comprising time zones or field zones and preset layers, thereby eliminating the need for coding and reducing scenario structuring time and adjust graphical elements in real-time based on user input, environmental feedback, user view, and resource availability, thereby ensuring the feasibility of the even scenario as it is created. This enables intuitive programming.
The event generation processing unit captures, at a time of an operation by the drag and drop, limitation on time and a location that cause a problem during actual distribution, and visually notifies an operator that the operation is impossible when it is not feasible.
This makes it possible to avoid generation of an event that disables operation.
Here, “visually notifying the operator” includes, not only a case of actively displaying a display indicating the warning to the operator, but also passive display through disabling placement of the icon or the like at that location even if attempt is made to perform the drag and drop operation (disabling placement even if attempt is made to place).
The event management system further includes a general user participation processing unit that processes participation of the general user in the event when the event is being executed.
The general user participation processing unit can execute, by arranging an icon on a screen, processing in which the general user acts as a participant and causes a trigger in an event created by a manager user.
This makes it easy for the general user to recognize and be aware that the general user will participate in the event.
The event generation processing unit enables execution of calculation processing and condition processing necessary for an event, through a transition between objects by using a condition evaluation arrow and an assignment arrow, that is, joining operation.
This can expand a range of visualized programming.
The event management system further includes a general user interaction management unit that manages interaction of the general users who participate in the event. The general user interaction management unit can confirm a service target person at that time through each time evaluation in a transition sequence of a member scope, by using a graphical creation icon for overall processing (see
The event management system further includes a user action confirmation unit that confirms an action of the general user who participates in the event. The user action confirmation unit can confirm an action of the general user when the general user reads and transmits any one of a two-dimensional barcode, a one-dimensional barcode, an IC chip, an RFID, infrared information, or the like with a terminal, and the event generation processing unit can incorporate action confirmation of the general user into a scenario by using an icon, in order to enable the processing. This enables further reliable action confirmation of a user in a relationship with any one of the two-dimensional barcode, the one-dimensional barcode, the IC chip, the RFID, the infrared information, and the like that have been established in the land.
The event generation processing unit can create a scenario so that a user recognizes message distribution necessary for action management of the general user in accordance with importance, and the user action confirmation unit can manage an action transition of the general user during scenario execution so that the user recognizes message distribution necessary for action management of the general user in accordance with importance.
This makes it possible to attract attention of the general users who participate in the event, by providing guidance according to their hobbies and preferences and situations through the message distribution.
The event generation processing unit has a user interface that enables event creation or event participation through a mobile touch panel operation with only a thumb by using a tab and a scroll management icon. This enables operation while holding the mobile terminal with one hand.
The event generation processing unit can be configured to control, with a user interface or a user qualification, limitation of three-layer levels of a basic description of level 1, advanced management introduction of level 2, and overall processing (see
Here, there is no higher difficulty degree between level 2 and level 3. Both are descriptions having a higher difficulty degree than that of level 1 in parallel. That is, the action management and the participant interaction management are descriptions having a higher difficulty degree than that of the basic description.
The event generation processing unit can convert a scenario component that is graphically created, into a shared module for library registration. This enables a part of the program to be a template.
The event generation processing unit can perform editing by mutually switching between a normal edit screen showing a structure of the time zone and a map-type edit screen showing a structure of the field zone. This enables editing work that is easily understood intuitively, by switching the time zone and the field zone depending on the situation.
The event generation processing unit, in addition to generating an individual instance of a user by an entry trigger given with a function of generating an individual scenario instance of a user in any of a global trigger, RSS, RSS with user information, data from a cooperation system, data with user information, or a scenario status, can start a local entry process with a local entry that is an entry trigger for receiving only an action and field-in of a terminal carried by a user. This allows participants to participate in events that can be easily participated geographically, via signboards, posters, or digital signage with a two-dimensional barcode, or through terminal operation when they are in sight.
Position designation information of the local entry can specify position point information in addition to range information, and position point information is derived from position designation information such as user designation or a barycenter of a range. This enables handling with discrimination from a normal entry.
On a trigger map that is a map used to realize the local entry process, local entry position information being in operation for which a context is specified is displayed, in addition to a specified field zone information of a context being participated, and displayed local entry information is limited to one point information of a local entry to prevent unlimited range designation by a manager side, and position point information provided by one scenario or a manager user is limited. This enables handling of local entries on the map.
Furthermore, there is further provided a user check unit, and an event participant generates and selects a two-dimensional barcode page corresponding to a node through which the event participant is passing. This enables announcement of an own situation to a manager and other users in a form that can be handled by the manager and other user.
The general user participation processing unit categorizes a tag registered by a user with an alternative official tag, and registers as a participant attribute. This enables an attribute of the participant to be checked.
An attribute and data handled by the event processing unit during calculation processing include matrix calculation and query calculation using a table of a spreadsheet or a column of a database. This enables wide utilization of external information and the like.
Furthermore, the module, the time zone, and the field zone have an expected time element according to internal logic, the event generation processing unit further includes an expected time calculation processing unit, and based on a result calculated by the expected time calculation processing unit, validity of a scenario is determined. This enables determination in advance whether or not the scenario can be executed.
As described above, the event management system of the present invention can provide an event management system having a structure conforming to a structured document such as HTML, while making a user interface easy to understand at a time of scenario creation and scenario participation.
Hereinafter, a best mode for implementing a management system of the present invention will be described in detail with reference to the accompanying drawings. Until then, there are views illustrating an embodiment of the present invention. In these figures, parts denoted by the same reference numerals represent the same things, and basic configurations and operations are similar.
Furthermore, there is provided an API registration processing unit 61 that receives and register an API conforming to a predetermined API definition specification from an API provider terminal and registers in the API database, facilitating extensibility within the system.
In addition, there is provided an event generation processing unit 62 that transmits, to an event creator terminal, a predetermined event definition specification and an API freely selected from APIs stored in the API database, and receives an event execution program that is generated with, as a component, an API received in accordance with the event definition specification in the event creator terminal.
There is provided an event registration processing unit 63 that registers, in the event database, an event execution program conforming to a predetermined criterion of feasibility in this system and a validity criterion of an event freely set by a manager, and log data generated during the execution of the event, allowing for persistent data storage and retrieval in support of real-time event management from among the generated event execution programs. An event registration processing unit is configured to automatically analyze and validate event scenarios in real time by detecting and addressing constraints such as time zones, field zones, participant availability, and physical resource conflicts, wherein validation includes real-time constraint analysis and providing dynamic feedback to the manager user during scenario creation.
There is provided a communication processing unit 64 that is configured to manage real-time data exchange and low-latency synchronization between the server device and the user terminal, enabling synchronized event status, participant actions, and scenario execution, and allowing real-time adjustments to event flow based on ongoing participant feedback and live location updates.
There is provided a chart diagram interpretation unit 65 that interprets the structure of time zone or field zone information in the graphical scenario, including relationships between contents, transitions, and icons representing event modules, converting the interpreted graphical structure into a format executable by the event management system which enables seamless transition from the visual design phase to event execution, provide automated, real-time validation of the graphical scenario by detecting inconsistencies, invalid transitions, or resource conflicts, and alerting the manager user of these issues while dynamically adjusting the scenario based on real-time feedback and resource updates, facilitate real-time adjustments to the scenario and continuous validation of event execution based on participant feedback, location updates, and resource availability, thereby optimizing event flow for real-world conditions.
There is provided an analysis structure generation unit 66 that, in accordance with information interpreted by the chart diagram interpretation unit, analyzes a nested relationship of the time zone to structure a plain field as a top-level time zone together with property information, adds the field zone as a top-level element, lists contents and a descriptor included in each of the time zones as elements at a corresponding position in the structure together with property information, adds the icon subjected to portion arrangement, as a child element of each element (property), and adds transition information as a property and instruction information from both directions.
As a result, an analysis structure is generated and set as a structure unique to a chart, that is, a module, and chart interpretation equivalent to programming in a markup language is realized. Note that, it is also possible to provide one having a function as an interpreter language in module units, without generating the analysis structure.
There is provided a point management unit 67 that manages a point and a title that are profits given by a manager user to a general user. Here, the points have a monetary value, for example, they can be converted into electronic money. The title is an honorary title. There is provided a general user participation processing unit 68 that processes that the general user participates in the event when an event is being executed. There is provided a general user interaction management unit 69 that manages interaction of general users participating in an event. There is provided a user action confirmation unit 70 that confirms an action of a general user who participates in an event.
Hereinafter, an explanation is mainly given to a specification of a computer program to be installed mainly in a server computer in a case where the management system of the present invention is configured by connecting the server computer and a user's terminal via the Internet.
This service is a visual programming system for construction of a simple app for an event organizer (manager user) to provide a distribution service according to a location and a real situation (context), to a participant (general user) having a mobile terminal, with use of terminal distribution.
Therefore, the manager user creates an event scenario or imports an event scenario from a library, and then localizes to implement the event. Therefore, the system provides the following services to the manager user and general user.
A target commercial function is as follows.
See 1-4-1: scenario level for the above levels. (Skill level required for a manager user or a developer)
Using a Sample after Party
There is a live show at a nearby arena, and a bar owner has considered to use this system to guide guests returning from the live show to the own shop by using materials provided by a promoter.
This service will be explained with reference to a case of “live event after party” prepared as a sample.
A rock concert is held at a municipal stadium. Suppose that there is a sports bar that provides a venue for an after party at a facility attached to the venue or an adjacent place. A general user enters from a local entry (poster and the like) of the sports bar.
A concert organizer provides information materials about today's concert to an event of an associated advertiser (who has set up a local entry (LE) in the stadium by paying an advertising fee). The sports bar is installed with an audio visual (AV) terminal, and can broadcast distributed data. The shop has position information that can be confirmed by GPS.
At a time of entry, seats are reserved, and guiding to the shop is made. Entrance check is made at the shop. There are two information materials. First one is edited video of today's concert. Second one is a quiz based on today's details. Three different questions are distributed in each group. The shop can accommodate up to three after-party groups. The quiz must be conducted fairly and at the time desired by the group members. The results for individual groups are displayed. When the party starts, the edited material is broadcast except during the quiz.
A scenario usage flow will be described with reference to
A manager user creates an event in accordance with an implementer-side routine, and manages by distribution.
A general user participates in an event by a procedure of a user-side participation routine.
In addition to the entry by the general user from the local entry, this service can be made available to a general user through distribution by the event organizer to a terminal of a participant who has a mobile terminal.
When the created scenario satisfies predetermined outer requirements, it is possible to register as a “feasible scenario”. The feasible scenario is “tested”, and returned to the creator side to re-edit when there is a problem. The procedure of re-edit, registration, and testing is carried out until a defect is eliminated, and the feasible scenario is completed.
The feasible scenario has information on a period for advertising for collecting users to participate (advertisement start, advertisement deadline). An implementation trigger causes a start of scenario execution, and an entry trigger causes realization of user's participation in the scenario. When the implementation is ended, the scenario becomes an executed scenario after the attribute registration, and modularized. Those registered by attribute registration are subjected to attribute saving after validity verification.
General users apply after seeing advertisement announcement. After the invitation reception and the invited event participation authentication process (attribute check, participant type (see
In the attribute check, an attribute value of an attribute holder that can be referred to by the manager is compared with an attribute condition of the participant type (see
Participation of general users from a local entry (LE), such as access from a two-dimensional barcode provided on a poster, is also accepted by a similar procedure.
Invitation registration can be performed until a timing of the deadline for advertisement of the scenario.
Accounts will be described with reference to
Accounts are classified into a general user account and a manager user account.
Both are identified by an authentication e-mail address and a password.
While items are as shown in the figure, the manager user can issue a certain number of general user accounts for testing.
Rating: By rating, general users can limit events that can be participated. If a scenario tag has a relevant rating, the user cannot apply for that event. (Lockable with password).
Persona: General users can control personality to be disclosed at the event with a persona. In this system, the manager and other general users can only know information set in a persona, other than information specifically determined to be disclosed. It is possible to have a plurality of personas. However, personas other than a main persona cannot be used at an event unless they are linked to an app.
Ideally, anyone having an account may become any of a person who invites and a person who is invited for an event. However, demanding an ability for running an event from everyone is harsh. An entrance of general users who are only invited is made easy as possible. For this reason, a general user account and a director account are provided.
The user account has information such as an authentication e-mail address, a password, private information (name, age, gender), rating (selected from unlimited, R18 inhibited, R15 inhibited), a persona (although it is set for each terminal, it is also possible to use the same persona for multiple terminals. For example, when the same user uses a smartphone and a tablet together), a registered terminal (may be one or more), a persona tag, self-introduction text, various histories, and the like. In
General users may be allowed to participate for free without charge at the beginning, but charging information can be registered from the beginning and a payment method and billing-related information can be registered in advance.
The director account performs identity authentication with an authentication e-mail address and a password. A director may be an individual or a company. In a case of an individual, private information (name, age, gender, address, phone number, used e-mail address) is registered. In a case of a company, company information (company name, name of person in charge, department name, address, phone number, used e-mail address) is registered. In addition, for example, by providing grades such as grade 1 to grade 5 to the account, and making a difference in a scale of events that can be held, it is possible to enable upgrade according to actual results (results of the number of visitors, sales results, payment results, and the like). Account grade information about which grade each director has is registered.
In addition, information about charging information (payment method, billing-related information), a director name, a director tag, director introduction text, and various histories is registered.
A profit model assumes monthly charging (according to a usage capacity) to the director account, pay module usage fees, advertising revenue, and communication board creation fees. In the future, a fee proxy collection fee to the director when using a charging module for users, a usage amount when expanding an attribute holder capacity, priority user charges, module market transaction fees, and the like can be considered.
Regarding general user accounts, basically, the director side and the advertising side identify the persona (only age and gender can be used with user permission).
When the director charges the user in the own system, registration is required after transition to the own system (cooperation is searched for within a possible range).
Control is performed by graphically describing an operation of an object layered by a module into a scenario chart attached to each module. Interpretation and analysis are performed on a completed chart diagram to realize programming equivalent to programming in a markup language.
There are levels of complexity depending on things to be done with a constructed scenario, in producing the scenario.
Everything is allowed when a manager account is acquired, but the level should serve as a guide in modularizing tutorials and officials.
The first level is suitable for scenarios where actions of participants are not controlled by the system, but guided in accordance with real world situations.
At this level, only individual processing of participants is performed, and no interaction or overall processing (see
The second level is a level for performing action management of participants (progress support of an event).
This level is for scenarios based on the premise that actions of participants are guided and controlled by the system. Therefore, a mechanism is introduced in which important decision and selection of participants are supported, and multiple guidance is made for participants who take actions outside the purpose of the event by extending a range of exception management.
A status type at the end is classified and managed depending on how user's reaction in content processing is strictly managed.
Regular action is assigned to selection of a participant who is making a desired choice in progress of the event, and is issued by assigning a regular terminal status at the ending and important progress points.
Irregular action is assigned when a participant makes a choice that should be particularly controlled by the manager user in progress of the event, and is issued by assigning an irregular terminal status at the ending and important progress points.
Exceptional action occurs when a systematic exception occurs, a timeout occurs at a time of advanced management selection, or a field-out that causes an exceptional action occurs. When advanced management is selected in content processing, when a timeout trigger occurs without the participant performing a prescribed action, a timeout occurs and exception management is performed.
A module designated for the exception management is managed particularly on the event monitor (see
The third level is a level for performing interaction of participants and overall processing (see
In order to realize scenarios including an attraction that assumes interaction between participants, communication, rarity management, and grouping, a concept of overall processing (see
Processing targets are organized through an overall processing (see
An event proceeds by the manager describing interaction between a trigger and participant's reaction into the scenario.
A factor that causes the trigger is to be a start point of a transition arrow as a status trigger, and is linked to a status receptor described in detail in 3-3-1-5: Descriptor (processing icon, transition arrow, and trigger icon) to drive the scenario.
Entry processing: A start of the event and an entry of participants are controlled by a start option of
Event start is started by being specified in the start option of a feasible scenario. An overall processing (see
When the participant's entry is performed depends on whether an ETM is arranged in a first-layer non-overall processing (see
In a case without the arrangement, an event implementation timing is the same as the participant entry timing, and all entries up to the advertisement deadline receive the same processing (at different timings).
In a case with the arrangement, details of processing differ depending on whether or not the entry with ID information is performed.
For participants who have already participated, processing is performed in accordance with a transition line by a trigger of the ETM issued first regardless of the first layer or lower layers. For subsequent entries, processing is also performed by the ETM that occurs each time (for participants who have participated after the previous (general) ETM event).
The ETM that receives an individual ID processes the participant in accordance with the transition line.
An ETM associated with local communication means (including QR) of a terminal is called a local entry, and is specially managed.
The local entry is registered on various screens of a trigger checker, and is shown to general users as a point where the entry is possible.
An individual ETM of a second layer or lower functions as long as an overall processing (see
Further, an ETM in an opened individual processing instance functions as an OSTM.
See
Scenarios may have a layered structure depending on an arrangement relationship of modules.
A module arranged in a chart description of a certain layer or a property of an external module (see
The layers therebelow are generated when a generation trigger receptor of individual and overall processing (see
When there are multiple generation triggers, multiple contents instances may be generated at the same level.
Contents described in each chart and property screen are regarded as child elements of the module.
A content, classified zones, and attributes have a definition module, and can be referenced and arranged in a layer therebelow. In addition, attributes share an attribute value (contents behaviors differ for each arrangement module).
User attributes belong to a scenario.
A network service provides the following services to each of a manager user (user who has a director account) who creates a scenario and manages an event to be participated by a general user (user who has a general user account), and a general user who participates in an event by using functions of a mobile terminal.
To the manager user, provision is made as a web service using a browser, by using a manager screen and call equipment for emergency response.
To the general user, provision is made through a web service using a browser of a mobile terminal, or an app in a terminal having a function of 1-5-2. The functions 1 to 4) can also be realized by a browser.
Important common logics and business logics are listed here.
In a basic description, there is no participant interaction, there is no overall processing (see
In overall processing (see
A first-layer overall processing time zone (TZ) behaves as a TZ on an overall processing scenario instance starting from a time when the implementation trigger occurs.
The overall processing module drives the overall processing and issues a signal to members forming a member scope.
The overall processing (see
The overall processing (instance) is connected to individual instances through some connection descriptions, but basically is driven by transitions by overall processing transition arrows.
A module instance (individual) is processing for an individual instance (an instance is targeted rather than a member).
Since the description of the overall processing introduction level becomes more complicated, it is necessary to provide a gate for an interface to take confirmation (in simple processing, the overall processing description is limited to arrangement of the overall processing module).
As triggers, an implementation trigger and an entry trigger are prepared.
In a case where the entry trigger is not arranged in a first-layer description, the implementation trigger and the entry trigger have the same meaning. When the implementation trigger occurs, the scenario instance and the overall processing instance are generated for all the registrants.
In a case where the entry trigger is arranged in the first-layer description, the implementation trigger and the entry trigger have different meanings. The overall processing instance is generated when the implementation trigger occurs, and the scenario instances are sequentially generated when the entry trigger occurs.
An outside trigger description module (OSTM) designs a selection occurrence condition from a list of events that can be designated as an outside trigger. It is an external module. An OSTM having a function of adding an individual user ID ignores other IDs in an individual event.
An entry trigger description module (ETM) is an outside trigger description module (OSTM) given with a function of generating an entry trigger of a user. In some cases, an individual user ID can be given.
A local entry (LE) is an ETM having a function of adding an individual user ID to a trigger by local means (terminal action). The LE has functions of participation registration and individual instance generation.
When an entry trigger icon is made available, a degree of freedom in soliciting users is increased, and a complicated system can be realized.
Alternatively, a specification relating to the entry description may be determined depending on whether the first layer is the overall processing module or is for performing an individual normal processing (only).
When the first layer is the individual processing (only), the entry trigger is processed as a simple outside trigger, all invited participants are entered when the implementation trigger occurs in the entry processing (a scenario instance generation process for individual participants), and processing for participants in a subsequent advertisement period starts from the first layer when receiving an entry trigger at any time. Participant routes are distinguished only by the participant attributes given at the time of participation).
When the first layer is the overall processing, a participant will be incorporated into the member scope if there is no entry trigger. Individual processing will be received as needed in accordance with progress of the overall processing by the implementation trigger. When there is an entry trigger, an invited person (standby person) at a time of entry trigger generation, or a bound individual ID holder will receive a service according to a transition starting from the trigger.
Among triggers that can be described as an outside trigger, ones that are bound with an individual user as a terminal action include the following three.
Barcode detection: Reading an exclusive two-dimensional barcode and the like such as a poster.
App input: Entry input of an app of a cooperation system. IC reading, terminal proximity communication means, and the like.
Position information (location trigger): When the app acquires position information associated with a field zone.
The triggers that can be described as an outside trigger also include a global trigger. For example, it is distribution (RSS) of an article (see
The triggers that can be described as an outside trigger include a signal from a cooperation system. There is possibility of being bound with an individual user.
A trigger that is not associated with an individual ID causes individual instances of all users registered at the time of an occurrence.
An entry trigger of the second layer or lower when the entry trigger is not arranged in the first layer is regarded as a simple outside trigger.
In the individual instance, handling of the ETM that has not caused the entry is to be OSTM handling.
In the first layer, a module template, a scenario, an implementation trigger, an entry trigger, an individual scenario instance, and an overall scenario instance are described. A definition module can also be attached to the template. This is to reduce a module operation in a library and palette reflection.
A content can be used in a chart of a scenario attribute definition module or in a layer therebelow.
Even if definition is made with the same name, the definition can be added on an icon to be used as another attribute, in a case of being on another module.
Basically, a scenario attribute is one value for a defined module. All inputs in layers below are put into one place.
For definition of a content, reference possibility is basically defined. The contents that have become a child element regardless of a defined position generate an instance when receiving a generation trigger. (A behavior of an external module is not guaranteed=allowed even when being unique to the definition).
In
An unauthenticated user who accesses a site enters a login page. An authenticated user and a logged-in user enter User home of a main persona (
The unauthenticated user on the login page logs in if an account can be inputted, otherwise transitions to New registration page.
A user who succeeded in creating an account on the New registration page transitions to Account page. Each page has an all-screen common navigation and a category common navigation.
A login (out) screen, content full display, and a local entry do not have the all-screen common navigation.
The all-screen common navigation causes a transition to each of Account, User home (a user home of a main persona when a persona is not specified), Trigger checker entry, and Logout.
A transition is made from a list of contents to Persona management.
Persona-management-related common navigation causes a transition to each persona-management-related page.
A transition from a main block occurs as follows.
In Participation event home (started), a tab of the corresponding contents is displayed on the top
From a participation event with recent action
(Depending on details)
Participation event home (started)
Participation event home (unstarted)
From Invited event pickup!
Invited event individual home
Participation event home (started) relevant sub-screen
Participation event home (started) relevant sub-screen
Participation event home (according to a transition, see section *2-3,
Participation event home (started), Participation event home (unstarted))
Participation event home (according to a transition, see section *2-3, Invited event individual home).
Invited event individual home
Invited event participation authentication process
In addition to transitioning to each of the Invited-event-related pages, the Common navigation causes a transition to the following.
Invited event list
Participating event list
From sub-screen
Event explanation page full screen
The following may be added to the sub-screen depending on the event.
Invitation
Further, through a state transition,
Participation event home (unstarted)
From Common navigation
Participating event list
Invited event list
Participation event leaving
From sub-screen
Event explanation page full screen
Further, through a state transition,
Event start screen
Participation event home (unstarted) to Participation event home (started) through a state transition
Participation event home (started)
Participation event contents log
Participation event standby contents
Participation event displayed contents (list format)
In addition to transitioning to each of the Invited-event-related pages, the Common navigation causes a transition to the following.
Participating event list
Participation event leaving
From sub-screen
Full screen of displayed contents
Event explanation page full screen
From Common navigation
Participation event contents log
Event log list
From sub-screen
Event log full page
The following may be added to the sub-screen depending on the event.
Save recommendation attribute registration screen
Follow-up screen
Full contents display/log
Full contents display/standby contents
Full contents display
By clicking a header
Participation event home/a tab of the corresponding contents is displayed on the top
By clicking a header
Explanation is made in section *2-3 according to a state transition of Event home/Event
Entry screen
Trigger map
Available local entry
The common navigation causes a transition to each of the Invited-event-related pages
Invited event individual home
Invited event individual home
Invited event individual home
A behavior of the navigation bar is common to all screens. A screen-related navigation bar is arranged on the header as an icon.
Clicking causes a bar to appear between with the sub-screen, and clicking the icon causes a transition. For arrangement, all-screen common and screen-related should be aligned on the bar in parallel if both are called efficiently. When the icon on the header is clicked again, the bar disappears.
The remaining screen appears by scrolling down.
Binding
None
Essential screen elements
When an input to 1) matches an account, a login session is started. If there is no match, a warning alert is inserted on the screen and the process returns. #Login/logout
2-2-2: New registration
Binding
New registration
Essential screen elements
For an inputted password, for example, the following is scanned and confirmed.
It may be simply be described that it is OK when each condition is satisfied and there are eight or more characters (for example).
If the input is successful in checking of a and b, an account is created and a transition is made to the Account page.
Binding
User ID (omitted in the screen explanation below)
Essential screen elements
Three-choice radio type of: unlimited, R18 inhibited, and R15 inhibited
Clicking causes one row of a current password input form.
Two rows of new password input form when inputted.
Password change is made when correct input is successful.
Registration, editing and browsing, and management of persona information is performed.
Binding
New registration
Persona ID
Essential screen elements
Dormancy check
Delete
The sub-screen displays
This is a base of user (persona) activities, and new information can be confirmed.
Binding
Persona ID
Essential screen elements
Importance calculation logic (contents with high Wt is ranked higher)
(Explicit timeout remaining time*Wt1+elapsed time from display start time*Wt2+article with state with selection restraint? (0/1)*Wt3+is there attribute value input (form)? (0/1)*Wt4)*scenario importance (system designation) Wts=Wt #Hot contents display order calculation process
The Participation event home shows an example of participating in the Autumn Fuji Five Lakes Stamp Rally. The Participation event home is for a user called Heno Moheko-san, and displays tags for a transition to each of “Arrived at the stamp rally area”, “Guide module (first point)”, “Event leaving screen”, “Standby call”, and “Event explanation page”, and buttons for transitions to Event navigation and Common navigation.
Binding
Persona ID
Essential screen elements
What is handled here is to be a save attribute. See section 2-8 for the save attribute itself.
The Attribute holder has, for each user, information such as an attribute name, an attribute value, an attribute category, an attribute value type, and distinction of disclosed or non-disclosed. The attribute name is, for example, gender, age, prefecture of residence, occupation, participation scenario, and the like. The attribute value is female, 29, Wakayama prefecture, and the like. The attribute category is a provider of the attribute. The attribute value type is a character string, numeric value, true or false, and the like.
The attribute disclosure setting indicates whether other manager users can refer to. An attribute with a check box is a selectable attribute, and is disclosed when checked.
An attribute whose attribute value is described in a form is an attribute that can be edited by the user, and can be written or selected by a pull-down. In a case where the attribute is imported in the participation scenario, editing is disabled during participation.
A tag-related attribute depends on the tag, and the attribute is also deleted when the tag is deleted (false).
2-3: Event Home (Transition when Using Event)
Binding
Persona ID
Event ID
Essential screen elements
There is a log mode to display a log on a sub-screen in the Participation event home (started) and the Participation end event home. The sub-screen is added with a log screen with tabs reversed in the mode that allows browsing contents of a log format (3-3-1-10: Contents log). The log mode ends when all tabs of the log disappear. In the log mode, in the header, a message appears, indicating that the log is inoperable. #Log contents display
2-3-2: About Transition when Using Event (Event Start Screen and Invited Event Participation Authentication Process) See
In addition, an alert recommending editing and requesting participation reception again is displayed (a transition is made to the attribute holder in a case of following).
The user side can change the setting when it is a non-disclosed attribute, and can acquire the tag when it is a tag-related attribute, to adjust conditions.
However, a user who satisfies the condition of attribute check 2 is shown a warning message asking whether to reselect after adjusting the condition.
The list can be changed until the entry trigger occurs, and remains as one of the sub-screens.
The Participation event home (started) page will be displayed.
Contents that can be used by the user on this screen are an article (see
The generated contents are distributed by an e-mail and registered in the user screen as the active mode. Contents e-mail delivery: When contents are generated, an html e-mail with the same appearance is sent to an e-mail address designated by the user's terminal. At a time of the first action or when selecting a location where an event is not set, the browser or an app is called and the display is performed.
#E-mail delivery
The generated contents have three modes of
Active
Standby
Termination.
Contents of the active mode include an article being displayed (see
Contents of the standby mode include a standby article and a standby external module service screen.
Contents of the termination mode include an article in a termination state and the external module service screen
When a special article is deleted, a transition is made to the standby mode. #Content state control
Full display of contents is performed. Clicking the header causes the display to return to the original screen.
A special article is registered in Special article in Scenario screen of
Users can use external services in three forms.
User authentication: When using external services of A and B, in a case where personal information of the account or the cooperating service is used, Authentication confirmation screen must appear to make confirmation of the use. #Login/logout
All the lists must be able to adopt the order of new arrival, a reverse order, a load order (see 2-2-5: User home, contents other than logs) #Hot contents display order calculation process, and an order in which contents have been generated (event list). #Event/contents user list display mode set #Content state control
Binding
Persona ID
Essential screen elements
Content name
Event name
Generation time
List generation display of active contents during participation (unstarted, started).
Clicking the contents name causes a transition to the Event home, and sets display of the sub-screen to the corresponding contents.
Binding
Persona ID
Essential screen elements
Content name
Event name
Generation time
Clicking the contents name causes the contents to be changed into a state of being displayed, and causes a transition to the Event home, and sets display of the sub-screen to the corresponding contents.
Binding
Persona ID
Essential screen elements
Event name
Entry time
A list of participating events (unstarted and started) of the persona.
Clicking the content name causes a transition to the Event home of the corresponding event.
Binding
Persona ID
Essential screen elements
Event name
Entry time
A list of invited events for the persona. See 2-3-2 for the range.
Clicking the content name causes a transition to the Event home of the corresponding event.
2-5-5: Event log list #Log contents display
Binding
Persona ID
Essential screen elements
Event name
Entry time
A list of Participation end events of the persona. Each item is linked to the Participation end event home.
Binding
Persona ID
Event ID
Essential screen elements
Content name
Event name
Generation time
A list of displayed contents for the participation event.
Clicking causes a transition to Contents full display.
Binding
Persona ID
Event ID
Essential screen elements
Content name
Event name
Generation time
A list of standby contents for the participation event.
Clicking causes a change into a state of being displayed, and causes a transition to Contents full display.
Sorting is similar to the Hot contents (excluding the state of being display)
Clicking the collectively-displaying button causes the entire list to be changed into a state of being displayed.
Binding
Persona ID
Event ID
Essential screen elements
Content name
Event name
Generation time
A list of contents in the termination state of the participation event
Clicking causes a transition to a log mode of Participation event home, and displays the corresponding contents.
2-6-1: Trigger checker entry
Binding
Persona ID
Essential screen elements
Binding
Persona ID
Essential screen elements
Local entry name
Event name
Distance
Binding
Persona ID
Essential screen elements
Local entry
Started event (participating) #Location trigger acquisition display
See
Local entry process
A tag has a structure as shown in
An official tag includes an official important tag having an attribute value, and a part of the official important tag is grouped and has a group label and a tag value. This is called an alternative official tag.
An example of the alternative official tag group
Group label: Eternal age
Tag Tag value (type)
From 0 to
Eternal 22 years old 22 (numeric value)
Eternal 23 years old 23 (numeric value)
Eternal 24 years old 24 (numeric value)
Up to 90
A normal official important tag takes a true/false value when converted into an attribute.
Alternative official tag has the group label as the attribute name, and the tag value as the attribute value.
The attributes of deleted tags are automatically deleted. #Tag-attribute conversion mechanism
See
In order to realize the interoperability of the value, setting management is made possible on save attributes with management right on each of the manager side and the user side. For this management, the manager side can use 3-4-4 Registration recommendation save attribute management, and the user side can use 2-2-6 Attribute holder. For the manager side to use in the scenario, it is necessary to designate usable save attributes as a reference destination of an import attribute, and to designate as an attribute condition of the participant type (see
Save attribute properties
The synchronization is performed at a time of Attribute registration in
Attributes derived from user account information. The attribute value cannot be edited but selectable to be disclosed. Two items, gender (character string selection) and actual age (numeric value), are applicable. Further, a user who has downloaded the app to the registered terminal obtains an “app user” attribute (true or false).
Attributes derived from tags. It is automatically registered and deleted as an attribute by the process described in detail in 2-7 (
The save recommendation attribute is a save attribute for which the manager side has the management right, and is linked with the manager ID with the management right. Definition and management of the save recommendation attributes are performed on 3-4-4 Registration recommendation save attribute management page.
Registration usage process
See Registration recommendation attribute new registration process in
See
In a case of approval synchronization, approval check is clicked. When the other party's approval (denial) is obtained, an e-mail is received. When the list is checked after that, the attribute has been approved and is to be treated the same as being disclosed. In a case of denial, the attribute has been denied, and the manager user cannot use the attribute.
Since only disclosed (approved) synchronization (or self attributes) can be saved as the save attribute, only a process thereof is extracted. #Participant type (see
When contents are generated in each event, the contents in a log format (3-3-1-8: Log) is distributed in the html format to the terminal e-mail address of 2-2-4: Persona management. When the user clicks the screen or takes the first action, sub-screen display of the corresponding contents is called and displayed by the browser.
See 3-4-6-1: Announcement e-mail delivery.
When a warning is issued by the system side, a typical automatic transmission e-mail is sent.
When e-mail delivery is performed to an app DL terminal, push communication is performed at the same time. The specification is according to the service used. mBaaS and the like.
A trigger refers to “event” for driving the entire event, but refers to, for the user side, a trigger associated with a field zone currently receivable in the participating event. This is tentatively called a location trigger.
A field zone associated with field-in/out and having a transition arrow leading to contents in an active time zone that does not eventually transition to exception management is to be a definition of the location trigger (considering explicit limitations by attributes). An exception location trigger for exception transition is also defined.
In a special article on the sub-screen, a trigger checker entry, or a user check two-dimensional barcode issue module, the user can generate and display a unique two-dimensional barcode for a terminal that identifies the user's terminal and a context of the scenario.
By causing this two-dimensional barcode to be identified by a two-dimensional barcode reader on the manager side or a reading function of the user app, a trigger can be caused. Trigger identification is performed by registering the two-dimensional barcode on the manager side with 3-3-4-3-1: Outside trigger description module.
For contact between users who do not have the app, an input code and an input form valid during the event are also displayed at the same time.
The user can transmit contact information between with manager side equipment or users, by using the two-dimensional barcode or the input code displayed on the page. This is called a user check.
When an exception termination margin and a zone out margin are applied, warning distribution of a message is performed (2-9-2). When countdown is set to be permitted by the user side, warning distribution of the countdown is performed at regular intervals.
For new registration, see 3-6 New registration. Screen transitions of the manager user having authentication are described. The screen is sectioned into a main navigation that comes in the header, a sub-navigation that extends vertically, and a main block that displays information. See
Information of main navigation is common to all screens, and a transition list of sub-navigation is changed in accordance with selection of the main navigation.
Scenario creation (see
Scenario management
Event monitor (see
Account
Log out
Sub-navigation does not exist.
Contract renewal page such as upgrade
Payment page
Inquiry
Existing APIs that can be used are actively used, if any
From sub-navigation
Welcome page
After scenario selection (scenario list by a pull-down, and new creation)
Scenario
Scenario chart
Article creation (see
Module creation
Contents list
Participant attribute management (see
New article creation (special article)
Participant attribute management (see
Modularization (data convert) #Scenario transition control
Outline check (transition) #Outline check
Feasible scenario (data convert) #Scenario transition control
From Utility bar
New calculation module
New article
New module
New scenario attribute
Scenario attribute management #Contents list (cut out)
Private library (scenario ID) #Library transition
Standardized library (scenario ID) #Library transition
Article list screen #Contents list (cut out)
New production
Article being created
From Utility bar
Preview #Article description-User image conversion
Private library (scenario ID, article ID) #library transition
Standardized library (scenario ID, article ID) #library transition
Module edit screen (fill-up) #Class/template
Module edit screen (definition change) #Contents list (cut out)
Content list (see
Scenario
Module list screen #Contents list (cut out)
New production
Module being created
From Utility bar
New calculation module
New article
New module
New scenario attribute
Scenario attribute management
Fill-up #Class/template
Definition module change #Definition/scope
Private library (scenario ID) #Library transition
Standardized library (scenario ID) #Library transition
Contents display
Attribute display
Sub-element display
Layered display
Each contents edit screen (article ID)
From New attribute registration form
Importable attribute list #Importable attribute list
Participant type (see
Attribute chart call #Scenario/calculation chart
From sub-navigation
Welcome page
Feasible scenario
Participant management
Registration recommendation attribute management #Save attribute management
Private library #Library transition
External standardized library #Library transition
Announcement e-mail delivery #E-mail delivery
Two-dimensional barcode generation
Each scenario creation (see
Participant attribute browsing screen #Save attribute management
Invited event list #Referenceable user confirmation process
Attribute detail informing
Attribute registration form call
From sub-navigation
Welcome page
After scenario selection (list of ongoing events)
Chart monitor (see
Manager trigger management (see
Exception module monitor (see
Attribute value list #Event activity
Participant list #Log management
Upper-level chart monitor
Contents property screen (contents ID) #Event activity
Module chart monitor #Chart monitor
Module property (module ID) #Event activity
Activity (module ID) #Event activity
Manager call (module ID)
User log display (user ID) #Log management
Module property (module ID) #Event activity
Activity (module ID) #Event activity
Chart monitor (user ID) #Chart monitor
Emergency call #Emergency processing
Activity (module ID) #Event activity
Binding
None
Essential screen elements
When an input to 1) matches an account, a login session is started. If there is no match, a warning alert is inserted on the screen and the process returns.
See 3-6 New Registration
Binding
Manager ID
Essential screen elements
Binding
Manager ID
Essential screen elements
None
A part for performing a process of creating a scenario until registering as a feasible scenario. 3-3-1-1: Chart #Scenario/calculation chart
A chart is a mechanism that is used in 3-3-3: Scenario chart, 3-3-4-1: Nest type module, 3-3-3-6: Calculation module, 3-3-1-6: Timing setting, and 3-3-1-13: Participant type (see
A completed chart has a flowchart shape in which a content is linked by transition arrows, and the transition arrows are relayed or sectioned by icons of control objects (descriptors, zones, attributes).
By using a sectioning relationship by the transition arrows and the time zone (3-3-1-4-1), and using a position on the screen to analyze a relationship of contents and a descriptor, behavior control information is extracted.
There are two types (five types) of the chart, which are a scenario (module) chart to manage a state transition of contents, and calculation charts to define attribute calculation and conditional branching (there are a timing setting chart and an attribute condition chart as variations), and some of usable objects are also different.
The five charts are desired to have the same (composite) function and differ only in a palette that appears (it is regarded that a difference between arrangeable icons of the scenario type and the calculation type is classified with the calculation zone. Further, there is still a difference in interpretation after arrangement due to a difference in module functions).
The chart is sectioned into some pieces, and has different types of palettes that appear depending on the screen used.
Scenario chart: Scenario chart (3-3-3-2: Chart area)
Module chart: Nest type module (3-3-4-1: Nest type module)
Calculation chart: Calculation submodule (3-3-3-7: Calculation submodule)
Timing setting chart: Timing setting (3-3-1-6: Timing setting)
Attribute condition chart: Participant type (see
A chart surface without any icon is called a chart field, and a chart field not included in a time zone is called a plain chart field.
There are three actions to be used; click, double click, and drag and drop (DD).
Mode of icon on chart field: An icon or a portion selected by clicking is highlighted. The following operations are all operations on a selected portion or icon.
Mode of mouse point: Double-clicking only a transition arrow on a palette causes a mouse point to resemble the transition arrow of the corresponding type, and to have a special behavior. This is canceled by clicking and double-clicking the transition arrow again.
When DD is performed on an icon on a palette, the icon silhouette moves with the mouse point. If a developed icon can be arranged in an empty portion on the chart field (see 3-3-1-1-1-6: Movement limitation), the icon is displayed. When the icon is dropped at that position, the icon is displayed at that position with an appearance that has been set on the field.
When the icon subjected to DD reaches a position where the icon can be arranged on another icon, a frame line changes to an emphasizing color. When the icon is dropped at that position, the another icon changes to an appearance in which the icon is arranged in a corresponding icon portion. Double-clicking the combined icon or portion cancels the arrangement, and separates icons are displayed. An icon that cannot be displayed on the field disappears. A field zone can be arranged on another icon by performing DD on a DD area on the FZ icon.
This is similar to contents, but a property is determined by arranging an icon of a processing palette on a chart field.
3-3-1-1-1-3: Movement of Icon within Screen and Transformation of Icon #Mouse Pointer Mode
A selected icon on the chart field can be moved by DD while maintaining a relationship between a transition arrow and an arrangement icon. Other limitations are the same as those in 3-3-1-1-1-1-1: Arrangement on chart field.
3-3-1-1-1-4: Joining operation of transition arrows #Mouse pointer mode
For a transition arrow appearing on the chart by the arrangement on the chart field, portions at both ends can be selected. One end of the selected ends is fixed to a connectible portion (start point: status trigger/end point: status receptor) by DD, similarly to 3-3-1-1-1-1-2: Arrangement on icon and icon portion. Cancellation is also possible by double-clicking. The transition arrow with both ends joined is highlighted.
In a case where the mouse point changes to a specific transition arrow, when a start point clicks on the status trigger, a transition arrow appears in which the start point is fixed and a tip end follows the point. In that state, an end point is connected by clicking the status receptor. Further, when a transition arrow is double-clicked in mode designation, the transition arrow disappears.
When a selected icon or icon portion is clicked, a menu related to detailed information or an independent operation of the icon appears (if there is a setting). The icon is deleted from here.
Icons other than transition arrows cannot be arranged overlapping with other icons.
Further, a field zone can only be arranged in a plain field.
Limitation and expansion of icons that can be arranged in a calculation zone.
Completion chart: The following requirements must be satisfied. #Transition control
In the member restriction part,
Using these to drop and connect allows further restriction of the range.
Attributes of numeric type attribute value can be arranged here. The determination value arrangement part also serves as an assignment destination of an assignment transition arrow, in the calculation chart. Further, a value can be directly inputted through a numeric input form.
A plurality of any attributes can be arranged here.
3-3-1-1-2: Interpretation and analysis #Chart interpretation
3-3-1-1-2-1: Information to be interpreted
In a completed chart diagram, information having meaning in interpretation is as follows.
3-3-1-1-2-1: An Analysis Structure is Generated by the Following Procedure in Accordance with Information to be Interpreted (Extracted from Generated Information of Html).
This is a structure specific to chart=module.
With the above, the interpretation of the chart becomes equivalent to programming in a markup language.
The above operations are preferably performed together with arrangement, joining, and separating operations for warning of limit operations and presenting future guide information.
The term “contents” is a concept of a set of multiple pieces.
A content is representation, on a scenario, of a service (and lower-level modules) actually used by a user on a mobile terminal. A content icon receives a transition arrow, and issues behavior information in a form of a status with an attached icon that represents a terminal status, an attached field zone, or a system status. In a case where there is an input form inside, a participant attribute may be changed. This can be confirmed by a usage attribute of the contents list. #Transition control
The content is broadly classified into an article and a module.
The article is sectioned into a message and an article (with a state).
The module is sectioned into four parts in accordance with a normal module, an exception management axis, a nest type module, and an external module axis.
The content has a member restriction part, and attribute conditions that can be generated can be set. #Member restriction
All contents arranged on a chart are displayed in a container of icons called a contents palette (including new blank icons). The icon is arranged on a chart or on an article edit screen by dragging or the like, to be used. #Palette
Definition of the content is performed through sub-navigation or clicking on a new icon for new contents, and is performed, for editing existing contents, by clicking the icon on the chart, the palette, or the content list (see
For the edit screen, details are defined in 3-3-5-4: Description screen for articles, and 3-3-4-1: Nest type module for modules. Further, the external module is called as a template (next item). #Definition/scope
A relationship between icons on the palette and icons on the chart is to be a relationship of a child class having details exactly similar to a class, and a change is basically reflected in everything else no matter where details are edited and changed. However, when editing is performed as a copy, another icon appears on the palette and becomes a different class. Note that the operation of dropping another icon on the icon does not correspond to the editing. #Class/template
Scope: A module for which New creation is called is to be a definition module, and it is possible to change by using Definition module change on the edit screen. Although it is easy to redefine at an upper-level layer to expand a scope, lowering the layer or redefining outside the scope causes arrangement contents that are out of the scope to be individually independent copied contents.
A range of the scope is as described in 1-4-1. #Definition/scope
Contents whose module is a definition module is shown inverted in the contents palette. #Definition/scope
See
The outer specifications are: a contents category; a type of a status at which a transition arrow starts or ends; a pattern, a category, and a type of a usage attribute; and a category and a type of an attribute. Member information of an overall processing attribute is not guaranteed. (A status where a terminal is dropped is excluded)
Only an attribute can be designated for a variable icon of an article.
A variable icon for a module is to be contents, a wildcard, and an attribute.
In a case where a plurality of the same contents and attributes are arranged, all are designated when one place is designated, and all are replaced when one place is replaced. In this case, the outer specifications (particularly a status from which a transition arrow starts) are composed.
Although it has been described that there are three modes of
Active
Standby
Termination
In state management, advanced management designation can be performed for a content.
Advanced management designation content: A content for which advanced management is performed causes a timeout and an exception termination unless a restraint selection terminal status is issued.
When the advanced management designation is performed in an article and a nest module, a selection restraint box can be called, and a status emitter can be arranged therein.
If none of these status emitters is selected, a timeout will eventually occur to cause exception processing handling.
Regularly processed content
Regular termination (termination)
Regular status issued active (active)
Irregular processing content
Irregular termination (termination)
Regular status unissued active (active)
Standby (standby)
The regular status unissued active and the standby are irregularly terminated when a timeout trigger occurs in an affiliation time zone.
Regularly processed content
Selection restraint regular termination (termination)
Selection restraint regular status issued active (active)
Irregular processing content
Selection restraint irregular termination (termination)
Selection restraint irregular status issued active (active)
Exception processing content
Exception termination (termination)
Selection restraint status unissued active (active)
Standby (standby)/article and external module service screen only
When a timeout trigger occurs, the selection restraint status unissued active and the standby (standby) cause a timeout and are exceptionally terminated.
If there is an exception processing content or a time zone before timeout, TZ cannot be closed until timeout. In an external module, it is requested as a module specification.
In a nested type module
In normal designation, exception termination does not occur even if exception processing occurs internally. Exception termination may occur in advanced management designation.
In the nest type module, a state is defined by both an internal transition and an external TZ, and an end event of an upper-level module.
Regular termination: When any of the regular processing status emitters is selected, there is no unarrived transition arrow, and all the call contents are processed regularly, modules without continue settings are closed, and a regular termination status is issued. Presence of a continue setting leads to regular termination after an occurrence of a timeout trigger.
Regular status issued active: A case where a regular status is issued from the module. Occurrence of a timeout trigger leads to regular termination.
Irregular termination: When all unarrived transition arrows do not exist, and call contents and TZs are all ended, modules without a continue setting are closed, and an irregular termination status is issued. Presence of a continue setting leads to irregular termination after an occurrence of a timeout trigger.
Selecting a forced-termination receptor leads to termination regardless of whether or not there is a continue setting.
Regular status unissued active: Generated and in a state other than the above. An occurrence of a timeout trigger or forced termination due to an external factor leads to irregular termination.
Standby: There is no standby state.
Selection restraint regular termination: When any of the selection restraint regular processing status emitters is selected, there is no unarrived transition arrow, and all the call contents are regularly processed, modules without a continue setting are closed, and a regular termination status is issued.
Selection restraint regular status issued active: A case where any of the selection restraint regular processing status emitters is selected, and there is no exception processing contents and no TZ at that time.
Selection restraint irregular termination: When any of the selection restraint irregular processing status emitters is selected, there is no unarrived transition arrow, and all the call contents are processed regularly or processed irregularly, modules without a continue setting are closed, and an irregular termination status is issued. Presence of a continue setting leads to regular termination after an occurrence of a forced termination trigger.
Selection restraint irregular status issued active: A case where any of the selection restraint irregular processing status emitters is selected, and there is no exception processing contents and no TZ at that time.
Exceptional termination: A case of forced termination except the above.
Selection restraint status unissued active: This is a state of not forced termination other than the above. An occurrence of a timeout trigger causes a timeout and leads to exception termination.
Standby: There is no standby state.
In an article, as shown in
In a case of using external data such as images, videos, and setting information in a content, a usage method differs depending on the user type. The manager user registers data in an allowed format into a library, and drops from a library data palette to a data receptor of a content or a screen part to use.
The data format that can be registered is enabled by a palette description for the content or the screen part having the corresponding receptor.
For a user, usage is enabled by a more limited way.
In accordance with screen parts of an article provided to the user or instructions of an external module, data on the own terminal is uploaded to the corresponding object. At this time, a data format and a generation timing are often limited.
It is recommended that the timing is created within a generation period of the object. Further, it is also possible to incorporate a call into the object so as to enable detailed settings in the timing setting chart.
Both articles and messages are blog-format contents created and edited by 3-3-5: Articles/messages. As functions during an event, the following functions are provided.
Since it is responsible for everything from the function of prompting to browse articles to action control of event participants, there are a plurality of pieces of state information as explained in 3-3-5-2: Article state transition.
In order to make this clear to the creator, articles whose state information is only distribution are regarded as messages, and other articles are regarded as articles, and icons are also distinguished. #Content state control
A module (described in detail in 3-3-4: Module) is obtained by cutting out a part of the scenario event management process as a separate object for easy handling. The module has an interface as a content regardless of internal behaviors. These modules can be regarded as child elements of a top-level module that has an interface as a scenario. Nest type modules are layered to be handled because they can further have modules as child elements.
This structural relationship of the modules must be grasped internally as a scenario structure (scope). #Transition control
While the exception management is described in detail in 3-3-4-2: Exception management, the exception management is monitored by 3-5-3: Exception module monitor (see
Modules are classified into a nest type module internally controlled by a scenario chart, and an external module controlled by a property screen.
While the nest type is described in detail in 3-3-4-1: Nest type module, it is necessary to arrange a terminal status emitter on a chart in order to obtain an interface as a content. The nest type module is to be a part of the layered structure. #Transition control #Definition/scope
While the external module is described in detail in 3-3-4-3: External module and 3-7: External cooperation, the external module is for using external apps, services, and calculation resources in order to be responsible for functions that cannot be realized by the nest type. There are an outside trigger description module that receives external information, and a guide module that performs guiding to a destination. Further, it is also possible to perform acceptance setting on data in the library in a data format, and perform settings and data input in advance. #External cooperation #External data usage
This is a setting of an amount of delay of actual application when an exception termination occurs. Determination is made by designating time in each setting, but it is also possible to set in module or scenario units.
A message is issued to a user at a time of detection, and listing is performed at the top level of the Hot contents. In a case of the nest module, wt of the Hot contents of the internal contents that are not regularly processed in standby and during display is weighted by a certain value.
When a contents icon is arranged on a chart, some accompanying icons are generated and attached. Further, an attribute or a field zone is accepted as portion arrangement.
In accordance with a property as a status trigger,
Among them, the termination state status can be used in three modes, and causes the following list to appear when clicked.
Regular termination (regular)
Irregular termination (irregular)
Exception termination (exception).
When selected, an icon for that mode is attached, and an undefined termination state status appears adjacently. When all three modes appear, there is no further increase. These issue a status in accordance with internal behaviors, and evaluate connected transition arrows, if any. When the termination state status is issued, the contents enter the termination state.
In accordance with a property as a status receptor,
These cause an event that drives internal actions when connected transition arrows are evaluated.
When the occurrence status is evaluated, the occurrence status creates an instance of the contents.
The trigger receptor causes a corresponding trigger icon inside to issue a status.
On the status trigger and status receptor described above, portion arrangement of a scenario attribute icon can be performed. The arranged attribute icon changes an attribute value in accordance with a mode at the time of arrangement. See 3-3-1-3-7: Individual explanation of behavior on attribute chart.
When portion arrangement of a field zone is made in an icon body, the field zone becomes an affiliation field zone, and is attached with a small FZ icon, a transition non-generation icon, and a field-out icon. See 3-3-1-4-3-1: Affiliation field zone
Transition non-generation (exception)
Field-out (exception)
Setting
Exception termination margin setting: Time is set. Defaults for modules and scenarios are initially described. #Termination margin
Member restriction: There is a member restriction part on a left shoulder. When an icon is arranged and a condition is failed, transition non-generation is issued. #Member restriction
An attribute is an object that is used for recording control of user's action information, and using retained information on a scenario, and for control of group action. The attribute is similar to a variable, but has no name space and has a different scope meaning. In addition, the attribute is always bound to a user or a module (or both), and has an attribute value.
Further, attributes are broadly classified into two types. These are a scenario attribute and a participant attribute. The scenario attributes are further classified into a normal scenario attribute and an overall processing attribute, depending on whether having a representative value and member information. Further, there is an attribute property attribution icon to cut out and use various attributes and user properties.
All the attributes that can be used in that chart are displayed in a container of icons called an attribute palette (including new blank icons). The icon is arranged on a chart or on an article edit screen by dragging or the like, to be used as an assignment destination for value change, a condition, and a form.
A location where an attribute icon can be arranged on the chart differs depending on a type of the attribute icon, and a function also differs.
The attribute is identified by an ID given at a time of definition.
A data structure includes
For a participant attribute, active information for each participant type (see
An attribute scope in this system indicates an attribute palette of which module (scenario) or contents the attribute is displayed on.
A participant attribute is defined in 3-3-6-1: Attribute registration, and can be used in all attribute palettes in the scenario. However, some non-active participant types (see
A scenario attribute can be used in a defined module or modules of lower layer, or a contents palette. See
A normal attribute can have types of a true or false, a numeric value, a character string, a character string (list), and data as the attribute value types. Whereas, an overall processing attribute has a special type in order to control actions in parties.
True or false: True and false values are given. Participating users are treated as having false values by default in the scope. No value is given to a non-active participant type (see
Numeric value: Numeric information is given. Participating users are treated as having 0 by default in the scope. No value is given to a non-active participant type (see
Character string: Character string information is given. Participating users are treated as having a null value by default in the scope. No value is given to a non-active participant type (see
Character string (list): Character string information reserved in advance is given. Designation must be made at the time of definition. Participating users are treated as having a null value by default in the scope. No value is given to a non-active participant type (see
Data: A data format must be designated at the time of definition (an extension symbol appears in the icon). Data of a format required by screen parts and external modules can be designated as a type. Participating users are treated as having a null value by default in the scope. No value is given to a non-active participant type (see
A data format that can be designated is added when screen parts and external modules that use a certain format are registered as types in the palette. (Formats required for official screen parts and external modules can be designated by default) #External data usage
This is an object of an attribute type that is used for controlling users and progress of events on a scenario. The scenario attribute belongs to a user, and theoretically all users have the attribute once defined in the scope.
At some arrangement locations, the scenario attribute is handled as either a true/false value type or a counter type except for condition information, for transition control as a transition control mode. #Transition control
True or false: true/false value type (false: false/true: true)
Character string: true/false value type (false: null value/true: “1”)
Character string: true/false value type (false: null value/true: first value in list)
Numeric value: Counter type
It is possible to arrange at a location where arrangement is possible in
The counter type can be arranged in a loop value of other descriptors, a transition value arrangement part, and a counter arrangement part.
Locations where a scenario attribute of the transition control mode can be arranged
Terminal status
Evaluation status
Termination receptor
Content start timing
Transition unstarted
Trigger receptor
Time-in
Time-out
Forced-termination receptor
Processing icon (at evaluation start/at evaluation start and end for a counter type: an upper part and a lower part of an icon)
The processing icon is used as a normal type in a calculation chart, but when being used to control a logical transition arrow of a descriptor, the processing icon behaves the same as in the transition control mode. (Functioning as a normal type when connected with an assignment transition arrow) #Calculation zone
On both charts
An attribute arranged in an attribute drop part of an attribute pattern filter controls a behavior of the pattern filter as condition information.
Participant attributes are used for using, in a scenario, preference and value information provided by a user or a manager side. Whether or not the user has that attribute depends on the participant type (see
Cooperating of information outside the event is performed, such as cooperating with a save attribute.
This is an attribute having, as member information, an overall processing TZ or an overall processing module instance in a member scope or a designated area of a module that is unique to a definition module instance, or in a designated lower level. The overall processing attribute is used for managing actions in parties such as groups.
In addition to individual attribute values of members, information for overall processing such as a representative value and a representative property are given.
A value given with the overall processing TZ or the overall processing module instance as a dependency destination can have a user object as a value in addition to the normal type. When this type is given in the member calculation TZ or an honor-type group property acquisition mode (3-3-1-3-7: Individual explanation of behavior on attribute chart, section b)), relevant member information is assigned.
A representative value for the definition module instance and a member attribute value for the member may be given.
The overall processing attribute functions only in the overall processing module or a module with an overall processing description.
Further, specially, the overall processing attribute can take an order type and a group type by combining with a numeric type member attribute value and a list character string type.
The order type has order information unique to each member (guarantee). When members are divided due to attribute restrictions on the scope and the like, the order is reorganized within that division.
Order generation method of order type
Numeric type: Ascending order of numeric values. If the numeric values are the same, the one with an earlier grant time is prioritized.
List character string type: Descending order of ranks of attribute values in a list. If the character strings are the same, the one with an earlier grant time is prioritized.
The group type groups users who have the same member attribute value, with the value as a key. When a trigger connector is restricted by the group type and subjected to generation transition to another overall processing TZ or module, an instance is created for each group. (The member scope of the instance is to be the group member)
The instance type is a type whose member has the overall processing area and overall-processing-related individual processing as members. All instances in potentially arranged modules are members. When conformance is made, an instance of that a description is added to the member. (Strictly speaking, instance control of individual processing (such as multiple generation by multiple transitions) is not an overall processing, but is to be in a control range of the overall processing attribute (overall-processing-related individual processing area) since the operation is complicated)
Type of overall processing attribute
Representative value
True or false
Numeric value
Character string
Character string (list)
Data
User object
Omitted (member attribute value only)
Member attribute value
True or false
Instance-type true or false
Numeric value
Order-type numeric value
Group-type numeric value
Instance-type numeric value
Character string
Instance-type character string
Data
Instance-type data
Character string (list)
Order-type character string (list)
Group-type character string (list)
Instance-type character string (list)
User object (instance type automatically)
Omitted (representative value only)
An overall processing attribute arranged in an overall processing chart field or arranged in the above scenario attribute arrangement part can designate a member by sending a conforming arrow. Multiple designation may cause an active user and a non-active user. An attribute value of the non-active user is held, but the event is not affected during that time. The value can be manipulated by difference designation.
This is an icon that converts a property of an attribute into an attribute, and makes it function as a scenario attribute in a normal field. After arrangement first as a blank scenario attribute, the target attribute is arranged. The symbol*indicates that only reference is possible.
Scenario, participant attribute
Overall processing attribute #Representative value
Representative value member object
Description instance property icon*(unnecessary if a conforming target has already been specified by designating an extraction object with a conforming arrow, or arranging in a connector and the like) #Instance management
Locations where attribute icons can be arranged on the chart are as follows. #Transition control
In the transition control mode, the icon can have four states (arrangement mode). To change the state, by selecting and clicking an attribute portion after arrangement, the state is sequentially selected.
True value (+1) assigned (icon remains the same)
False value (−1) assigned (minus mark on icon)
Value inversion (inversion)
Property acquisition mode (P mark on icon)
In a property acquisition mode, a property acquisition list further appears, and a possible property for the attribute type is selected.
A) Contents, TZ generation, elapsed time (seconds) from idling start: numeric value
A current maximum rank for a representative value
A total number of groups for a representative value #Group management
A member object of the designated rank for a representative value
The honor functions as a normal scenario attribute in a normal field-outside the overall processing. The member attribute value changes on the overall-processing-related individual processing area, and the representative value changes in the overall processing time zone. In a group property acquisition mode, related information about the transition is acquired in accordance with the type.
A function of receiving and sending a logical transition arrow (normal arrow) as a part of a calculation cluster is also given.
An object called zone is used for controlling an elapsed time and movement on a scenario chart and to controlling the life of contents. For the zone, a time axis or a part of geographical spread is sectioned as a zone. Further, a status occurs when a user (terminal) crosses the section. For the status, since different statuses are issued for entry and exit, it is necessary to have information on whether the user is in the zone or not.
A zones that has been set is treated as contents, and appears on the content palette when classification is selected in settings. In a definition module, a time zone is to be a classified module, and a field zone is to be a scenario. Due to the nature, only one piece for each kind can be arranged on the same chart. Field zones imported from the library are also displayed in the content palette.
See
Further, a name and a timing setting are displayed inside a frame.
For the life of a time zone and contents arranged in the time zone, generation and existence are only possible within a range of the life of the time zone. Time zones can be nested.
Frames of the time zone cannot cross each other, and icons other than transition arrows cannot cross the frame.
A state transition of the time zone is as shown in
If the content does not end in time, a timeout will occur.
The timeout does not occur if the content ends normally, but when the timeout occurs, internal call contents and generated time zone are exceptionally terminated.
Time zone generation timing (time-in), transition non-generation of generation (transition non-generation time setting), and forced termination timing (time-out) are performed in the same way as the time zone timing setting. Described in detail in 3-3-1-6: Timing setting.
For the time zone, a continue setting can be performed in which the time zone does not end until a timeout occurs even if the ending conditions below are satisfied.
In addition, there is a member restriction part on a left shoulder, and conditions can be arranged.
In a case where there is no continue setting.
In the generated time zone, is there no irregularly processed contents, no evaluation transition arrow being evaluated, and no descriptor, has all the call contents been regularly processed, and has outgoing transition starting from the regular processing been made?
When these conditions are satisfied, it is regarded that the time zone has been regularly terminated, and a regular termination trigger is issued. See 3-3-1-2-1-2: Content state.
Similarly, even if the above conditions are expanded, and there is no unarrived evaluation transition arrow and no descriptor, and all the call contents have been regularly processed or irregularity terminated, the time zone ends without waiting for timeout (irregular termination).
When these conditions are satisfied, it is regarded that the time zone has been irregularity terminated, and an irregular termination trigger is issued. See 3-3-1-2-1-2: Content state.
A calculation zone is a special time zone with an equivalent function to the calculation module, and the life is treated as a moment (at the start, processing within the zone has the highest priority). When the calculation zone is arranged, a calculator palette is called. There are no accompanying triggers.
Calculators cannot be arranged in other than the calculation zone, and contents cannot be arranged inside the calculation zone.
See
While the time zone expresses a relationship in a form of including icons on the chart, the field zone manages the trigger in a form of being provided at an edge of the chart.
For life management of contents, association is made by dragging an associator to the contents.
The associated contents can be created and exist only during field-in. Associated field-out occurs as an exception for the first time at forced termination. Contents that have been processed regularly before field-out do not cause field-out. “Transition non-generation” occurs when a generation transition occurs during field-out.
Generation setting: An affiliation field zone can be set to generate an affiliation content when field-in occurs by icon setting. If the time zone or the arrangement module has not been generated, the generation will not occur.
This is performed by dropping a point marker on a called map as shown in
Field zone definition method: An icon to select the following mode is clicked, and then a marker is dropped.
Time from when there is a timeout occurrence event in the time zone until an actual timeout occurrence, and time from detection of the field-out occurrence event in the field zone until an actual field-out occurrence, and a distance from a border are called a zone out margin.
Determination is made by designating time and a distance in each setting, but it is also possible to set in module or scenario units.
A message is issued to a user at a time of detection, and listing is performed at the top level of the Hot contents.
Zone designation frame: The time zone has a designation frame for sectioning chart fields. The field zone also has a similar icon to emphasize commonality as a zone, but this is just an icon.
A shape is a rectangle, and drag point is arranged so as to enable movement and transformation by dragging (standard ones are fine).
The rectangle must not be crossed by anything other than a transition arrow (apart from the member restriction part).
Only a conforming arrow can be connected with the frame itself (drag point and the like?)
Time-in: This has an arrow shape, and is automatically arranged at an upper part of the designation frame when a generation timing setting is performed. A tip end is a status trigger and a root is a status receptor. However, if there is no trigger or trigger+description in the start timing setting, the receptor does not function. In that case, when a connected transition arrow is evaluated, the start timing setting is evaluated, and a status trigger is issued when tz generation occurs.
Time-out: This is an arrow directed opposite to the time-in, and is automatically arranged at a lower part of the designation frame when a termination timing setting is performed. A tip end is a status trigger and a root is a status receptor. However, if there is no trigger or trigger+description in the termination timing setting, the receptor does not function. In that case, when a connected transition arrow is evaluated, the termination timing setting is evaluated, and a status trigger is issued when timeout occurs.
Transition non-generation time setting: This is an arrow having a different shape from the time-in, and is automatically arranged when a transition non-generation timing setting is made next to the time-in icon, or when something is arranged in the member restriction part. A tip end is a status trigger and a root is a status receptor. However, if there is no trigger or trigger+description in the transition non-generation timing setting, the receptor does not function. In that case, when a connected transition arrow is evaluated, the transition non-generation timing setting is evaluated, and a status trigger is issued when the transition non-generation occurs. A TZ subjected to transition non-generation is not generated.
Regular termination: This is an arrow having a different shape from time-out, and is automatically arranged at a lower part of the frame. A tip end is a status trigger. A trigger is issued when the time zone is regularly terminated. Clicking on the icon causes a change to an irregular termination mode, and another regular termination icon appears adjacently (no change even when clicked)
Setting icon: An icon is in a part inside the frame. There are characters of Setting. Clicking causes detailed settings to appear.
The settings are displayed and the following processing can be performed. #Scenario/calculation chart #Transition control
When it is performed, a generation setting is displayed in characters in the upper right when a condition filter in the condition setting is one or less. If the condition filter is more than one, a condition icon marked as Generation appears at the corresponding position. A time-in icon appears.
When it is performed, a termination setting is displayed in characters in the upper right when a condition filter in the condition setting is one or less. If the condition filter is more than one, a condition icon marked as Termination appears at the corresponding position. A time-out icon appears.
When it is performed, a transition non-generation setting is displayed in characters in the upper right when a condition filter in the condition setting is one or less. If the condition filter is more than one, a condition icon marked as Transition non-generation appears at the corresponding position. A transition non-generation setting icon appears.
Member restriction part: There is a receptor icon in the upper left of the frame. When rejection occurs due to restriction, the transition non-generation occurs. #Member restriction
Zone icon: This has a rectangular frame shape. A member restriction part (left shoulder), a setting icon, and an associator icon appear inside, and a field-in trigger and a field-out trigger appear in association. When restriction functions, a transition non-generation icon is attached.
Associator icon: This is automatically arranged inside a rectangle. An icon represents an image of drag. Performing DD of this part onto a content generates an affiliation field zone.
Transition non-generation icon: This appears in an upper part of the icon when the member restriction functions. A shape is a bow and arrow shape, and there is a status trigger at a tip end.
Affiliation field zone icon: This appears in a part of a content as a belonging destination. A shape is a rectangle, and is a model shape for a field zone. A small field-out and a transition non-generation icon are attached. Member restriction part: There is a receptor icon in the upper left of the frame. When rejection occurs due to restriction, the transition non-generation occurs. #Member restriction
Setting: An icon is in a part of inside the frame. There are characters of Setting. Clicking causes detailed settings to appear.
The settings are displayed and the following processing can be performed.
This is an icon used together with a zone in order to manage a state of contents in scenario charts and calculation charts. See
In addition to a processing icon that appears in the processing palette, a transition arrow, a trigger icon, and a forced-termination receptor are normal descriptors. When the normal descriptors are added with descriptors for the manager call for exception management and for the calculation chart, and a descriptor for an overall description, these are expanded descriptors.
The transition arrow can be extended from a status trigger and connected to a status receptor.
Terminal status (evaluation status)
Contents termination state status
Contents icon generation/non-generation status
Trigger icon
Zone accompanying trigger
Specific portion of processing icon (individual explanation)
Scenario attribute icon placed directly on chart
Contents occurrence status icon
Contents trigger receptor
Accompanying trigger for zone with trigger description in timing setting
Specific portion of processing icon (individual explanation)
Scenario attribute icon placed directly on chart
Forced-termination receptor
Transition arrow: A flow of processing when a status occurs is shown. Only one transition arrow is generated from one status. A scenario cannot be completed if there is a transition arrow with no destination.
Single transition arrow: Thin line (only one reaction to trigger) Multi-transition arrow: Thick line (multiple reactions to trigger)
The multi-transition arrow is evaluated each time a trigger occurs. The single transition arrow is evaluated only for a trigger that occurs first.
If there is an occurrence receptor at a transition destination led by the multi-transition arrow, the contents can have multiple instances.
Incoming and outgoing of transition arrow for time zone frame: A transition arrow can extend beyond the time zone frame. This arrangement has special processing implication.
An incoming transition arrow only functions for the lifetime of the time zone. When such a transition occurs, a “transition non-generation status” specially occurs (in the internal contents) even if it is not the lifetime of the internal contents. #Content state control
A transition arrow that has actually made a transition (at some point) during a period of a module's active state is called an evaluation transition arrow, and a transition arrow that has not been evaluated is called a non-evaluation transition arrow (unevaluated transition arrow).
Processing icon: The processing icon controls the scenario by relaying transition arrows toward the content, and performing conditional processing or terminal processing.
There are normally seven types of processing icons. See
Consequential ending: A consequential ending status emitter can be dropped on only one of endings of logical transition arrows in the calculation chart.
When any transition arrow on the merge side is evaluated, all transition arrows on the branch side are evaluated. The single transition arrow on the branch side reacts only once, but the multi-transition arrow is evaluated every time the merge side is evaluated.
The scenario attribute can be arranged at an upper end in the transition management mode, and an attribute value changes every time the arrow on the merge side is evaluated.
The loop must be in the same time zone.
Note that formation of the loop only with transition arrows causes warning in the outer check.
Rejection occurs when the loop with only transition arrows crosses the time zone (at least a loop counter should be inserted if a child TZ is inserted).
This is to check for an unintended loop and to prevent that a loop that crosses a time zone is formed to make time management difficult. #Outline check
For a storage type of a content, a numeric value is given by default, and execution is made in an ascending order of the numeric value, each time a transition occurs with a loop and the like. However, contents satisfying a condition of the member restriction part of individual contents is executed. When the restriction is released due to a transition situation, the contents with a smallest number at that time are executed.
A terminal status is aggregated and arranged in the wildcard. In a case where a multi-transition arrow is not connected, evaluation is conducted only once at the first time. At this time, the status of the original contents is displayed with a light color. This status does not require a transition. This can also be used, and the status arranged with a transition arrow returns to the original color strength. Contents are stored inside when being dropped into the wildcard together with a conditioner, and the list can be viewed by clicking a card icon.
A field zone storage type is accompanied with field-in/out.
The field zone to be stored can have a sequence limitation property that accepts triggers in a sequence order. Without this, a trigger occurs every time field-in/out occurs.
It is also possible to receive member restriction.
If a content of a content wildcard connected to this field zone wildcard with a transition arrow contains a content of a trigger occurrence affiliation field zone, the content is preferentially activated. If there are multiple contents, an order of order designation of the card is applied.
Trigger icon: A trigger icon is an icon for introducing a trigger outside the module into the chart.
A start trigger icon is arranged by default on the chart, and it cannot be removed.
A new trigger icon can be arranged in two modes.
One is a manager trigger, which is given a name when it is created. This is unique in the scenario, and is registered with a name+a definition module name. A manager trigger once registered can be called from a manager trigger palette. Operation is made with 3-5-1-1: Manager trigger of the event monitor (see
The other one is a general trigger corresponding to a trigger receptor, and is automatically numbered and appears on the chart when it is generated. This creates a corresponding trigger receptor on the module's icon. Both can also be arranged inside the time zone, and will only function within the lifetime of the TZ in that case.
Forced-termination receptor: This is a status receptor that causes forced termination of a module. When evaluated, the module is terminated, which causes irregular termination. #Transition control
3-3-1-5-1: Individual Explanation of Behavior on Descriptor Chart (Other than Overall Processing) #Transition Control
Transition arrow: See 3-3-1-1-1: Chart operation and 3-3-1-1-1-4: Joining operation of transition arrows.
Single transition arrow
Multi-transition arrow
Ending icon: This is an icon designed to emphasize the fact of being ending.
Merge/branch icon: An upper part of the icon is a status receptor, and a lower part is a status trigger.
Transition arrow counter: This is similar to the merge/branch icon, but has a design that emphasizes the determination value arrangement part. There are a status receptor, a status trigger, and the determination value arrangement part.
Attribute pattern filter: This has a design that emphasizes the fact of being a conditioner. A status receptor is in an upper part of the icon, and a Y and N terminal statuses of a logical consequence part are at in a lower part. On a right shoulder, there is a condition attribute part. On a left shoulder, there is a mode display part showing a mode. The mode display part does not display when the attribute of the condition attribute part is one or less. In a case of two or more, two modes of AND and OR are taken, and the modes are switched by clicking the display part.
Comparison condition filter: The design is similar to that of the attribute pattern filter, and the status receptor and the logical consequence part are the same. There is a condition attribute part (form type) on the left and right, and normally an input form is displayed, but only one attribute can be dropped. When selected, the input form is displayed larger, and allows input of a numeric value, a character string, and a true/false value. Three types can be selected from a pull-down, and a heading of the form is changed.
There is a mode display part in the middle, and clicking causes switching between five modes: congruence, equal comparison, comparison, backward equal comparison, and backward comparison.
Loop counter: This is the same icon on the palette, but a top icon and a bottom icon connected by a line appear when arranged on the chart. The top icon has a status receptor in an upper part, a status trigger in a lower part, which similarly applies to the lower end. However, the design is reversed. Both have the determination value arrangement part, and an attribute can be dropped. Both cause the status trigger at the lower end to be issued when the corresponding icon reacts for the number of times of a determination value. The determination value arrangement part where nothing is arranged becomes infinite.
Wildcard: Content-like icon. This is stored by performing DD on the content icon. A terminal status of a storage content appears. Clicking causes an internal content list to be called.
Details are the content list (see
Selecting Development causes the list to disappear, and a mouse pointer transforms into a silhouette of the content. Clicking on the field causes display of an icon of the content connected to the wildcard at that place. Only the status trigger functions for that icon.
Trigger icon: This has a design that emphasizes a trigger. There is a status trigger. Further, a color of the start trigger is different, and there are characters of Start. A trigger name is displayed for a manager trigger. Numbering is displayed for a normal trigger. When the trigger icon is arranged, a list for selection of Manager or Normal is displayed. When nothing is selected or when Normal is selected, the numbered normal trigger is arranged. When Manager is selected, a name input form appears, and arrangement is made as the manager trigger when input is performed.
Forced-termination receptor: This has a design that emphasizes its meaning. All are status receptors.
See
Information required for a timing is acquired in three ways.
Which are
The trigger occurs each time an accompanying icon or an icon receiving a transition arrow receives a transition. Although details of the trigger cannot be classified, it is possible in practice by using the attribute. #Transition control
The time setting can be set in five ways as shown in the table.
Explanation: Evaluation is conducted by arranging each piece of iconified information as editing of a calculation chart. #Scenario/calculation chart
In a timing setting chart described later, an input form appears after the trigger icon is arranged from the palette, and designation is made. In a case of the reference module instance starting time designation, an upper-level nested module part of the content list (see
Clicking a corresponding item causes a calculation chart to be called, and displays the attribute palette and the trigger palette having the trigger icon in
For input of a time of day and a time, there is used a pull-down that appears when a cursor is placed on each input form for date and time that appears when the trigger icon is clicked after arrangement. In a case where the setting is ended with only a single attribute pattern filter, the timing setting is displayed in a space as a character string.
See
On a chart, contents can have a terminal status icon appearing as a start point of a transition arrow customized by the user. This function is realized by making it possible to cause a status when evaluation is conducted by dropping a status emitter on a possible portion of the module chart and the article edit screen.
The status and the emitter correspond to the same one letter (up to two letters) in the alphabet. These icons are displayed on a status emitter palette.
Regular status, irregular status, and logical consequence status: There are two types of status in order to distinguish between a process that is proceeding well in the scenario process, and a situation that requires a response. When an arranged situation occurs, the regular status emitter icon issues a regular status, and the irregular status emitter issues an irregular status. In a space of one letter, the last 10 characters of the alphabet are reserved. Y and N are reserved by the logical consequence status.
The logical consequence status is a terminal status displayed in a logical consequence part of a processing icon of a conditional type, where Y corresponds to a true value and N corresponds to a false value.
Consequential ending emitter: In the timing setting chart and the attribute condition chart, only one consequential ending emitter is described in the status emitter palette. Arrangement can be only made on one or more ending icons.
A palette is to be displayed as a drag source for arranging objects required for scenario progress on a chart or an article description screen.
Content palette (scenario chart, module chart)
Content palette with calculation module limitations (calculation chart, timing setting chart, attribute condition chart)
Attribute palette (scenario chart, module chart, article description screen, calculation chart, timing setting chart, attribute condition chart)
Processing palette (scenario chart, module chart, calculation chart, timing setting chart, attribute condition chart)
Manager trigger palette (scenario chart, module chart)
Screen parts palette (article description screen)
Status emitter palette (module chart, calculation chart, timing setting chart*, attribute condition chart*)
Calculator palette (calculation chart)
Trigger palette (timing setting chart)
Library data palette
Icons that appear in the palette are limited to icons whose module or article is within a scope. Icons with different definition modules are displayed with a name+a definition module name (root).
As shown in
Basically, there are many icons stored in the palette, and it is often impossible to display all of them. Therefore, three functions are provided.
The internal icons are arranged in accordance with a width, and rows are increased.
Pressing the fold button results in a bar only with the header, and developing returns to a size designated by dragging.
When a pointer passes over a displayed icon, a name of the icon is displayed.
Content palette #Class/template: A content, a field zone converted into a content, and a template that can be used in this scope are stored. Templates are handled as stored objects internally of a sub template palette. The template palette follows shape change of the main content palette, and can only be deformed vertically. When folded, the template palette is arranged in a bar shape at the bottom of the palette.
Searches are simultaneously screened by a main search condition.
The content corresponds to all articles and modules being created.
In the calculation chart, only the calculation module is displayed.
A frame of a content whose displayed module is a definition module is highlighted.
In addition, for a content whose definition module is different, a content name and a module name are displayed.
Attribute palette: Attribute icons that can be used for that scope are stored.
Scenario attributes, participant attributes, and attribution icons are displayed. If the chart is the overall processing area, attribution icons related to the overall processing attributes are added.
A frame of a content whose displayed module is a definition module is highlighted.
In addition, for a content whose definition module is different, a content name and a module name are displayed.
In an attribute condition chart of a participant type (see
Processing palette: Transition arrows, processing icons, triggers, time zones, calculation zones, field zones, overall processing time zones, and overall processing calculation zones are stored.
In a case of the overall processing area, overall processing icons, overall processing transition arrows, and conforming arrows are added. #Overall processing
Manager trigger palette: This is a palette that contains registered manager triggers.
Screen parts palette: Screen parts to be used for description editing are stored.
Status emitter palette #Transition control: There is a sub-palette for irregular emitters. The function is similar to that for templates.
Five pieces (A to E) of automatically-numbered regular emitter are displayed. Five pieces are added each time when a field of the palette is clicked. Double-clicking reduces unused icons by five pieces.
This similarly applies to irregular emitters. Initially Z, W, V, X, and U are displayed. Reserved characters are displayed sequentially.
Calculator palette: Calculators, logical transition arrows (the same as normal thin arrows), and assignment transition arrows are displayed. The handling of transition arrows is the same as the processing palette.
Trigger palette: The trigger icons described in detail in Timing settings are stored.
Library data palette: Data registered in the library and having a format that can be used for screen parts and field zone definitions is stored. For reflection, an import operation is required on the library side. The reflection is made by dropping in a data receptor of a screen part through DD. #External data usage
The purpose of overall processing is as follows.
Overall processing is driven by an overall processing description running on an overall processing instance.
An overall processing description needs to be described in the overall processing area.
Overall processing areas
Description can be made in the overall processing area (b and c are excluded from the overall processing area)
Overall-processing-related individual processing areas
Overall processing descriptions
The overall processing description can be connected only with an overall processing transition arrow excluding a trigger connector.
Only the overall processing attribute can be used on the overall processing area.
Individual processing can also be described in an overall processing description feasible area, which becomes an overall-processing-related individual processing area.
An overall processing instance is generated for each overall processing area. It is possible to have multiple instances in the same area through multiple transitions and group processing. The overall processing instance shows its own behavior by driving of the overall processing transition arrow.
Even when being described in the same chart field, the individual processing and the overall processing that are not in a slave/master relationship operate at completely different timings. However, both in the same chart can be related to each other by transition evaluation, with use of a connector.
For a layer for which the overall processing description is not made, in a case where a generation trigger in a lower-level layer generated by any of the individual processing instances occurs, the overall processing instance generates a blank layer instead of causing non-generation, and activates the corresponding description.
When there is an overall processing description, that processing is to be followed.
A member scope defines a range of interaction between an overall processing instance and a user. Specifically, it is a description method for: basic member scope designation of a range description of a connector, a time zone, and an internal module; member designation of overall processing attribute; and active and non-active member designation when evaluating active member differences.
Basic member scope: A module and a time zone have a basic member scope. The basic member scope constantly changes as active members are switched in time series. The basic member scope is a list of ad hoc members, and targeting a user who uses the module in an individual instance, an internal time zone, or a module instance.
The basic member scope of the overall processing in a normal module is an active user of the module and an inner element instance.
For the overall processing module, the user who is actively using a child module and the inner element instance are to be the basic member scope.
Icons that can conform (conforming body)
The symbol * indicates that only user conformance is possible. Description method
Operations on chart
Individual processing time zone body
Accompanying trigger/receptor for individual processing time zone
Individual processing module
Accompanying trigger/receptor for individual processing module
Overall processing time zone generation trigger/receptor
Overall processing time zone body
Overall processing module generation trigger/receptor
Overall processing module body
Overall processing attribute icon
Basically, conformance is confirmation of target member scope.
However, it may be an instance of the target object in a case of a trigger connector and an overall processing attribute. In a case of group designation, both are applied.
A conforming body that has conformed to the same processing (regardless of the main body or the accompanying trigger) or attribute.
See a-4 for member difference between these two types
See 3-3-1-1-1-7: Portion. (This is used to limit a range of the member scope in the overall processing area)
An overall processing module is driven on the overall processing instance, and may have a normal chart inside, or may be an external module.
A function as an area is the same as that of the overall processing TZ, but a child description can be arranged in an external individual processing module, which changes the member scope. Further, a trigger icon with an individual ID when a transition to a child module is made is generated.
When a transition is made to a child module before generation of the overall processing module, a module in which no event occurs is started. In this case, a child module generation trigger is issued together with the overall processing module generation.
The overall processing module has a member restriction part, and can incorporate the conditions of the above section b-4.
The basic member scope is all users who have child module instances created.
An overall processing time zone is processed on the overall processing instance.
The overall processing time zone can be described on the overall processing area and on a plain chart field of the normal module (functioning as a nest).
The overall processing time zone has a member restriction part, and can incorporate the conditions of the above section b-4.
The basic member scope is all users for which individual instances of modules with a TZ description are described (may be created).
The description of the overall-processing-related individual processing area is restricted by the member scope of the described overall processing.
Further, an overall processing attribute, a group transition counter, and an overall processing calculation zone can be used within the area (a member attribute value, and a representative value converted into an attribute).
It becomes a target of a conforming arrow, and provides user instance and object instance information.
3-3-1-9-7: Interaction Between Overall Processing and Individual Processing within Overall Processing Area #Transition Control
The interaction above is performed using a trigger connector, a group transition counter, and an overall processing attribute.
The trigger connector makes a transition from the overall processing to the individual processing within the overall processing area, and the group transition counter makes a transition from the individual processing within the overall processing area to the overall processing.
Basically, the trigger connector makes a transition from a member transition part to a user or a processing instance of the member scope of the processing.
The group transition counter collectively manages individual processing and makes an overall processing transition to the overall processing (re-transition to the individual processing is also possible).
The overall processing attribute holds an individual value of the member scope and a representative value that is unique to the definition module, performs an attribute value operation of the member and the representative value, and performs transition control.
There are two methods for how to designate processing for equal to or more than a certain value; a constant and a fulfillment rate (time management is also possible if a TZ is inserted). The mode is determined, and the designation is made by dropping an attribute in a method specification part or inputting a numeric value.
Member restriction (for performing totalization) can be performed (member restriction part).
By applying restrictions with the group-type overall processing attribute, the processing can be performed for each group. (When there is no group information in the overall processing of a return destination, it is regarded that multi-transition has been performed (if the actual transition arrow is a single transition, reaction occurs only once at the first time).
A trigger part can perform the normal transition, the overall processing transition, and the group transition (restricted with a group-type overall processing attribute).
Group key information of group-type overall processing attribute
In a case where attribute values of the instance-type overall processing overall processing attributes are unique to each other
When used for generation transition of an overall processing instance, an identification key is given to each instance. After that, an overall processing instance transition having an attribute value key matching reaches an instance having a corresponding identification key (behavior of the group instance can be controlled by the key restriction). #Group management #Instance management
Group processing is performed by grouping users in the member scope of the overall processing, giving a group-type overall processing attribute, and generating an overall processing instance for group management by a group transition of a connector.
Grouping: A grouping key is given to a user who has been assigned with the same value into the attribute value of the group-type overall processing attribute in individual processing, and a user who has been given group information given by an external module by grouping and the like of 3-3-1-3-5-1: Member scope of overall processing.
Group processing overall instance: Modules and time zones created by the group transition of 3-3-1-9-7: Interaction between overall processing and individual processing within overall processing area have a key attribute value of a group-type overall processing attribute used as an identification key. Further, the user having the grouping key is set as the member scope.
After that, a transition to the group processing overall instance is possible for both the user and the instance, but a transition with a specified instance requires a group-type overall processing attribute for which key information is used for the instance-type attribute value or for generation.
Description is integrated in 3-3-3-6: Calculation module
Overall processing transition arrow: This is a transition arrow that drives overall processing. Similarly to the normal one, there are two types of a single transition and a multi-transition. The overall processing transition arrow can connect between overall processing descriptions, and can also connect an external group transition counter to the overall processing description.
Conforming arrow: An equivalent operation method to that of the transition arrow is applied. The conforming described in 3-3-1-9-3: Member scope is performed.
Trigger connector: A trigger connector icon has a status receptor and a status trigger for overall processing, a member transition part, and a member restriction part. The trigger and the receptor (see
(Overall processing) Processing icon: This is used in an overall processing description. A function is equivalent to the normal one, but the attribute that can be set is only the overall processing attribute (representative value).
Group transition counter: This icon has a status receptor and a status trigger, and has a method specification part and a member restriction part. The status receptor can only receive an individual processing transition arrow, but the trigger can send both the individual and overall processing transition arrows.
By clicking the method specification part, two forms for constant input and fulfillment rate input are switched and displayed. In the constant input mode, a numeric type attribute can be dropped.
Here, a calculation module using a chart including a calculation zone is described.
Calculations include a user individual processing calculation, and a member calculation in which a calculation including overall processing is added to the user individual processing calculation. To use the overall processing, it is necessary to be a chart including an overall processing calculation zone or a chart in an overall calculation module.
First, a basic individual calculation chart (see
A calculation submodule is a module for performing re-evaluation of a participant attribute or true/false evaluation calculation by using a scenario attribute and a participant attribute of a module to which the calculation submodule belongs.
Note that calculators cannot be arranged in other than the calculation zone, and contents cannot be arranged inside the calculation zone. The calculation zone is present in both the individual and overall processing. The individual calculation zone in the overall processing performs, as a member calculation zone, sequential calculation of the member scope of the corresponding overall processing.
A calculation submodule where a terminal status is not arranged at the end becomes a calculation submodule, and a calculation submodule where a terminal status is arranged becomes a condition submodule. This may include an attribute calculation cluster.
A calculation zone surrounded by this calculation module in the calculation TZ is called a calculation field.
Several specific descriptors are used within the calculation field.
In the calculation zone and the calculation module, calculation is performed instantaneously at the time of transition.
Attributes and the like are fixed at the time of transition, and are subjected to other effects after the calculation result is obtained (top priority processing by start time series).
For operations in the calculation field, logical transition arrows described below are evaluated by a conditional filter, and operations connected by assignment transition arrows that form a calculation cluster are procedurally executed to obtain a result.
In addition, a conditional calculation can be performed at the same time by modifying ending of the transition with a status emitter and issuing the evaluated status.
Content palette with calculation module limitations
Attribute palette
Processing palette
Status emitter palette
Calculator palette
In the content palette with the calculation module limitations, only the calculation module in the contents appears.
Logical transition arrow: This is used to realize condition selection and a procedural calculation process. This is actually the same as a normal transition arrow. In a case of a calculation zone, it is also possible to extend the normal transition arrow from outside to control evaluation timing of calculation.
As a specific connection destination in the calculation field, there is a connection to an icon forming a calculation cluster.
By performing actual calculation, the logical transition arrow generates an evaluation transition arrow and a non-evaluation transition arrow.
Assignment transition arrow: An assignment transition arrow connects an attribute or the like that acquires a value with a calculator, and also connects an attribute that assigns or uses the value and a condition attribute part or the like.
An icon group connected by the assignment transition arrow forms a calculation cluster.
A start point is called an assignment source, and an end point is called an assignment destination. Further, an assignment transition arrow with a calculator as the assignment destination is called an input arrow, and an arrow extending from a calculator to the assignment destination is called an output arrow.
It is possible to connect a dropped attribute or a numeric form with a calculation icon, or connect a calculation icon with an attribute, a condition attribute part of the comparison condition filter, a loop counter, and a transition counter numeric part. Note that, by directly designating an attribute as an output destination from the attribute or the numeric input form without inserting the calculator, the same value is to be assigned.
Start points of input arrow
Attribute icon
Constant input form
Calculator (assignment destination of another calculator)
End points of output arrow
Attribute icon
Condition attribute part of comparison condition filter
Determination value arrangement part
Calculator
Calculator: A calculator is an icon for processing and calculating information of an input arrow and outputting to an output arrow. There is provided one or more receptors that receive the input arrow, and one trigger that sends the output arrow.
There are two types of calculator receptors, single-input and multi-input, and a unique symbol that implies a function may be attached. Each input/output has type information, and only a matching value can be accepted.
The single-input receptor can be connected with one input arrow, and the multi-input receptor can be connected with multiple input arrows.
Example 1) Addition, subtraction, multiplication, division, and exponentiation
Adder: A/multi-input (numeric value) All inputs to A are added.
Subtractor: A/multi-input (numeric value) B/multi-input (numeric value) All inputs to both A and B are added, and B is subtracted from A.
Multiplier: A/multi-input (numeric value) All inputs to A are multiplied
Divider: A/multi-input (numeric value) B/multi-input (numeric value) All inputs to both A and B are multiplied. A is divided by B.
Power calculator: A/single-input (numeric value) B/single-input (numeric value) A{circumflex over ( )}B
Example 2) Average value, maximum/minimum value
Average calculator: A/multi-input (numeric value) Average of all inputs to A
Maximum value calculator: A/multi-input (numeric value) A maximum value of inputs to A is outputted.
Minimum value calculator: A/multi-input (numeric value) A minimum value of inputs to A is outputted.
Example 3) Round-up, round-down, random number generation
Example 4) Character string connection, character string cut out
Example 5) Logical calculator
Descriptor: Six types of processing icons are available: ending, branch/merge, a transition arrow counter, an attribute pattern filter, a comparison condition filter, and a loop counter.
All are used to realize conditional branching and procedural calculation of logical transition arrows.
The descriptor functions similarly to a normal field.
Constant input form: A value can be inputted from an input form, and a value can be sent to the calculator with an assignment transition arrow.
Calculation zone:
Calculation: When developing a directed graph with logical transition arrows in which the above elements are combined
Start point Conditional branch
Calculation cluster
Conditional branch Conditional branch
Calculation cluster
Ending point
Evaluated single transition
Calculation cluster Conditional branch
Calculation cluster
Ending point
Evaluated single transition
Multiple start points are allowed, and transitions can be merged, but such a tree graph is obtained when disassembled.
When actual calculation is performed, calculation along an evaluation transition arrow is performed at the conditional branch, and reaches the ending point or a transition stop.
In the calculation module, a status emitter can be arranged on this route, in which case a condition module is obtained. Even in the condition module, attribute calculation may be performed and an attribute value may be changed.
At this time, the result cannot be guaranteed if there is a calculation cluster that has the same attribute in another evaluation transition path.
There is a possibility that the evaluation is not made at the same time due to condition settings and the like, but such a situation should be warned.
Overall processing calculation field: An overall processing calculation module or an overall processing calculation zone is a called overall processing calculation field. In the overall processing calculation field, the same calculation as the individual calculation field can be performed by using an attribute value that can be used in the overall processing area.
Available attributes
Overall processing attribute representative value
Instance-type overall processing overall processing attribute member attribute value
Property attribution icon of overall processing attribute
Attribute value that can be used as member restriction information
Cooperation of individual calculation and overall processing calculation with use of member scope:
In an individual calculation zone in the overall processing calculation field (member restriction is possible), and in an overall processing calculation zone in which an instance-type or group-type overall processing attribute value is placed in the member restriction part, member calculation of the member scope is performed.
Further, it is possible to accept an assignment transition arrow toward an assignment destination of the overall processing (assigning an overall value to the individual calculation of each member), and an assignment transition arrow from an assignment source.
In addition, a multi-input of the calculator in the overall processing calculation field can accept a result of member calculation, and calculation is performed assuming that all individual values in the member scope are inputted.
A timing setting chart (3-3-1-6: Timing setting) and an attribute condition chart (3-3-1-13: Participant type (see
These charts are not modules and are not stored in the content palette.
As a common palette, a status emitter palette that stores only a consequential ending emitter appears. These charts ultimately require arrangement of the consequential ending emitter on one or more of the ending icons, to determine a condition. When the condition is satisfied, a timing or an attribute condition is regarded to be satisfied.
Timing setting chart: Since calculation of a trigger is included instead of evaluation of a value, it is not performed instantaneously but stepwise in accordance with an occurrence of trigger information. As a result, interpretation of a mode of an attribute pattern filter is partially different.
AND operation: When two or more triggers are included, evaluation is conducted only when all of them occur.
OR operation: When two or more triggers are included, evaluation is conducted when any one occurs.
Attribute palette
Processing palette
Status emitter palette (only for consequential ending)
Trigger palette
Elements available in a processing area appear in an overall processing area.
Attribute condition chart: This appears in a part where an attribute condition needs to be designated.
Places of appearance
Member restriction part
Participant attribute condition
Attribute palette
Processing palette
Status emitter palette (only for consequential ending)
Details of the attribute palette differ depending on a place of appearance.
In the member restriction part, an attribute according to normal place limitations appears (scope, overall processing area?).
In the participant attribute condition, importable save attributes are stored as a true/false value type.
An ended contents can be browsed from User event home as a contents log. Functions in progress of a scenario are lost, a form and a status link lose functions, and an attribute and status change from external cooperation are no longer accepted. Other links and video browsing functions remain.
A log is described as a history of a user or the whole in a structured language according to the scenario structure. Between an entry to module processing and a leaving description, an event that has occurred in the module is described together with time location information.
Detailed logs and contents data are stored at the cost of the manager side.
A User keeps the log for reference and minimum.
When the user needs detailed information (such as when creating an automatic blog), reference is enabled if the manager side releases or holds the data.
A participant type (see
Control is performed with a representative attribute (true or false) in a scenario.
Binding
Manager ID
Scenario ID
Essential screen elements
This is a block that manages a special article (see 2-4-2: Special article) of a scenario. The special article selected with a tab of 1-2) is displayed on 1-4) Main screen. At this time, a sequence number should be displayed somewhere. Further, check items on the 1-5 Type setting bar also change in accordance with the tab selection.
At the end of the tab, there is a tab for New creation, which, when selected, causes a block screen to appear with indication of Click after the type is checked. Clicking after checking causes a transition to the article edit screen in
This is displayed when a list of official tags is displayed and selected.
Information registered in 3-3-1-13: Participant type (see
See
Binding
Manager ID
Scenario ID
A screen is roughly sectioned into a main area and a utility bar in an upper part.
In the main area, a chart is basically expanded, and various palettes are placed on top of it. Positions of the palettes are variable. By default, palettes are arranged on a left side of the screen to make a palette area.
Essential screen elements
Utility bar
Main area is in the following section
A scenario chart is displayed.
3-3-3-3: Palette area (palette explanation) #Palette
A palette on the chart screen can be developed on the main area, and is initially aligned on a left side.
Content palette,
An edit screen of 3-3-3-6: Calculation module is opened, and at the same time, a corresponding module is registered as a definition module in the content palette. #Definition/scope
An attribute list for a range of the attribute palette is called. See 3-3-7-2: Scenario attribute list. #Contents list (cut out)
A transition is made to a private library of 3-3-4-5: Library use. (With ID information of a corresponding module)
A transition is made to a standardized library of 3-3-4-5: Library use. (With ID information of a corresponding module)
Type selection is performed in a state where a normal type selection screen is linked to a screen for selecting scenario attributes of the transition control mode, and a name is registered.
The name is in a state where an automatically-assigned name of 1?2 letters in the alphabet is in the form.
A registration screen called by New module is a creation screen for a nest type module.
Further, choosing Module creation in the sub-navigation causes a module content list (see
For exception management creation, a manager call appears in the processing palette by selecting an exception management of the module option, and the exception management creation screen appears.
An external module needs to be taken out from the standardized library. The selected library is registered as a template on a template screen.
See 3-3-1-2-3: Normal module and exception management.
Binding
Manager ID
Scenario ID
Contents ID
Explanation of an edit screen of a nest type module.
Essential screen elements
Sections 1-1 to 1-5 are same as those of the scenario chart. The module is to have the definition module opened.
When clicked, a palette containing the following icons appears.
By clicking again
See 3-3-1-2-1-1: Template and fill-up. #Class/template #Mouse pointer mod
When clicked, a list of definition modules and arrangement modules appear. Selecting causes a transition to an edit screen.
A function similar to that of the scenario chart is provided, but a status emitter can be arranged and an element can be made variable. Status emitters can be arranged in the following locations (see
Terminal status
Evaluation status
Termination receptor
Content start timing
Transition unstarted
Trigger receptor
Time-in
Time-out
On forced-termination receptor
Processing icon (at evaluation start/at evaluation start and end for a counter type: an upper part and a lower part of an icon)
Appearance palette
Content palette
Attribute palette
Processing palette
Manager trigger palette
Status emitter palette
Modules that should be focused on to be managed in event progress can be designated for exception management. Basically, a module that is likely to be difficult to proceed with a normal system is designated.
The module subjected to type selection of the exception management module is treated specially by the event monitor (see
Further, a manager call can be arranged as a processing icon (handling as an icon is equivalent to the ending icon), and it becomes possible to directly contact a user. See the manager call function of the event monitor.
The external module is an external API that has a service provision screen for users and a property management screen for a manager.
A behavior is required to follow limitations as a module (content) (appears as a template).
A status required for the content is issued.
Termination status
Start
Start not reached
The service provision screen is required to follow specifications of a contents screen for users. Specifications required for property management.
Essential
Fill-up is possible
Definition module change
Recommended
Changing to exception management is possible
Changing to advanced management is possible (manager side control is possible)
Making variable
Related reference list call
Library access
Graphical interface
New element definition of types required for property designation (calculation modules, modules, scenario attributes, articles, and the like)
Palette (content, attributes, emitters, library data)
Status emitter receptor
Content receptor
Attribute receptor
Data receptor
A selection occurrence condition is designed from a list of events that can be designated as an outside trigger. External module.
The OSTM calls a library data palette when arranged. This palette has a limited function, and only data registered as an outside trigger is displayed.
A property screen basically has only data receptors.
Further, there may also be a type having an attribute receptor to receive triggers whose data has properties (other than the individual ID).
When an outside trigger data icon is arranged on this receptor, a trigger is issued when an outside trigger occurs during the lifetime of this module at the time of an event. An OSTM having a function of adding an individual user ID ignores other IDs in an individual event.
There is also a module that performs complicated control for calling a timing setting chart. #Timing setting
In this case, the outside trigger is treated the same as the trigger.
Types of outside trigger
Global trigger
RSS
RSS with user information*
Data from cooperation system
Data with user information*
Terminal action*
Two-dimensional barcode reading
App input
Outside triggers with the symbol * have user information.
An outside trigger given with a function of generating a user's individual scenario instance is called an entry trigger. Depending on a category of data, there are those with designation of an individual ID and those without.
An entry trigger without the designation of the individual ID creates an individual scenario instance for all users who are currently in a participation state.
Multiple entry triggers can be arranged in multiple layers. The first entry trigger caused in combination with the user ID causes an individual instance of that user. At that point, other entry triggers are regarded as simple outside triggers. Entry triggers of the second layer or lower also cause individual instances in that layer. The following usage can be made even if an entry icon is not set.
A local entry is an entry trigger that accepts only a terminal action and field-in, and a registered user starts a local entry process on the spot (entry may not be immediately made). #Local entry process
Using a participant mobile terminal app, a contact confirmation process is provided between a manager user and a general user, and between a general user and another general user.
Mechanism to use the user check in the scenario.
Two types of modules are related
User check module
Overall processing conversion user check module
Special QR page issue module
A case where a manager desires to use the user check as a trigger in a specific module.
This associates the equipment with the class of the user check module.
Grouping occurs when users in a specific context perform user checks with each other. Grouping is performed for a group of two users by arranging a group-type overall processing attribute in the property. It is also possible to change both processes depending on a condition (a second method of checking by staff). If no condition setting is made inside, grouping is also possible by assigning a group-type attribute to A status.
User 1: B User 2: AB>User 1: B User 2: A
User 1: AB User 2: AB>Randomly assigned
The context can be limited also by dropping the module as the designated QR page with the property.
A guide module for guiding of a user to a specific point in accordance with the above specifications is created. This is important for services.
By converting a URL into library data, a specific web page can be converted into an external module.
This is basically treated as a message. When a generation trigger occurs, the other party page is called and displayed.
Selection is enabled by setting whether to capture and display on the content page or provide a link.
This is obtained by converting operations on AV equipment installed at a venue into an external module.
A property screen for management, and a data receptor and an attribute receptor for use of contents and user-provided information are required.
#Scenario behavior
When evaluated, a transition is made beyond the scenario for participants by issuing a scenario status or designating in a setting chart that contains library data of the entry trigger of the transition destination.
In overall processing arrangement, a transition is caused in all member scopes at that time.
When arranged, the scenario status receptor module is displayed on the scenario screen, and generates library data that serves as a scenario status when realization is enabled.
In a template in a module, contents, attributes, and field zones can be designated as variable icons. By designating one point of these, all arrangements of the same class become variable icons, and fill-up on one place is reflected in the same elements.
See 3-4-5: Library. Checked contents are registered in the library.
A scenario exists for distributing articles (and service screens of external modules) to participating users at appropriate locations, times, and conditions. Articles are the basis of communication between users and an organizer.
Article features
Therefore, state management is introduced for important distributions, to make it possible to determine whether user's reaction to the distribution is a regular action or an irregular action for progress of the event, or whether an exception has occurred. Explanation is made in detail in Article state transition.
A user screen looks like a blog article with a check button (other than messages) somewhere on the screen.
The article is displayed on a sub-screen of the user screen or in full screen display, and allows browsing of texts and videos, inputting into forms, linking, and selecting.
After reading the article, it is recommended to press the check button to confirm.
A message is displayed outside the frame and the like.
There may be a case where some work is needed to properly close the article before the check button is pressed. In this case, checking without performing necessary work causes a message to that effect to be displayed.
Details of the necessary work may or may not be explicit. When the check is selected, a confirmation message is displayed.
There are several types of articles to implement article state management, which change to several states depending on a status issue situation at the time of event execution.
Article type Exception occurrence selection With selection restraint
Types of 2) and 3) are articles whose state is generated by browsing management, and types of contents are classified into a message for 1, and articles for 2 and later (operations and creation methods are the same).
The article with state with selection restraint corresponds to an advanced management designation content.
Article state transition A) Regular ST/B) Irregular ST/C) Not generated F)
Terminated/O) Being displayed State
Message A/B/C F/O Message displayed
Article with state A F Regular termination article
A O Regularly generated article being displayed
B F Irregular termination article
B O Irregularly generated article being displayed
C F Standby article
C O Irregularly generated article being displayed
Article with state with selection restraint status Restraint selection A F Regular termination article
Restraint selection A O Regularly generated article being displayed
Restraint selection B F Irregular termination article
Restraint selection B O Irregularly generated article being displayed
A F Standby article
A O Article being displayed not selected
B F Standby article
B O Article being displayed not selected
C F Standby article
C O Article being displayed not selected
State: Each state is evaluated in accordance with whether to cause a timeout in a time zone, and which processing is to be received among regular, irregular, or exception processing.
Message displayed: This state is set when a message is delivered. A status or the like may be issued, but the state of the article is not affected, and regular termination is made as soon as the article is closed. Timeout does not occur.
Regular termination article: This is a state indicating that regular processing has been performed and the article has been closed. Regular termination is made, and no timeout occurs. Regularly processed.
Regularly generated article being displayed: This is a state where regular processing has been performed, but the article has not been closed yet. Regular termination is made when closed, and no timeout occurs. Regularly processed.
Irregular termination article: This is a state indicating that irregular processing has been performed and the article has been closed. Irregular termination is made, and no timeout occurs. Irregularly processed.
Irregularly generated article being displayed: This is a state where irregular processing has been performed, and the article has not been closed yet. Irregular termination is made, and no timeout occurs. Irregularly processed.
Article being displayed not selected: This is a state where article is open, but restraint selection has not been performed. When closed, a standby state is set. Timeout is caused.
Standby article: This is an article that is in a standby state and is out of a displayed list, but can issue a status when called. In a case of an article with a state, it is regarded as being irregularly processed, and a timeout is caused when having selection restraint.
Articles and messages can issue a terminal status as a content. Further, in order to make a user aware of browsing management, operation information that is the premise of a function is enabled to be registered in a check button. Furthermore, a selection restraint function is provided so that the event progress can be managed solidly.
It is the terminal status emitter that makes detailed determination on these functions.
See % % for explanation of the emitter itself.
Locations where the emitter can be arranged on the description screen
When the same emitter is arranged in multiple locations, a terminal status is issued when an event occurs somewhere.
Check box: An arranged emitter can be dropped in a check box. The check button starts functioning when all the same type of emitters as that having been dropped are selected. An empty box causes the check button to function without any preconditions.
When a check button becomes available, highlight display is made with informing of “Checkable”. Informing of “Not satisfying the condition” is made when clicked while being unavailable.
Informing can be edited through a text form in the box.
Restraint selection box: This is a box for setting a restraint selection status. It is possible to drop an arranged status emitter to be designated. Unless any of the statuses arranged here is issued, the termination state cannot be set until the TZ is closed. Further, that case also causes exception termination.
Screen configuration: A utility bar is arranged in an upper part, and an article main part and a palette are arranged in a lower part.
The palette is movable and can be freely moved within the lower part.
For users to perform video, input form, link, plug-in, and selection in the article screen, screen parts can be incorporated into articles.
Screen parts are stored in a screen parts palette, and arranged in a possible portion of the article by DD.
User image, description form, and receptor tab: The screen parts are present on the palette as an image of a category and a category name. Arranging this in an article causes a description form and a receptor tab to be opened. Since this is different from an occupied space, clicking a user image icon causes a user image edited at that time to appear at a designated position. Clicking a description form icon causes a transition returning to edit.
The description form is an editor for editing details of screen parts, and an interface differs for each type.
The receptor tab is obtained by combining an attribute receptor, a status emitter receptor, and a data receptor into a tab form, and is automatically arranged around the description form.
Check confirmation property: Check confirmation property often exists in an input-type screen parts. When this property is set, an emitter is selected at a time of checking, rather than at form input. During that time, input details can be changed. #Transition control
Alternative selection group: In a case where multiple certain input screen parts of the same type are arranged, alternative selection can be made by grouping the multiple pieces. In this case, a check confirmation property is automatically set.
Alternative setting: A title of an arranged input form of the same type is displayed by a pull-down. When selected, alternative settings will be listed. #Transition control
Status emitter receptor: A return value of the form is categorized into several types so that a terminal status can be attached.
Example
There is a check confirmation property for each receptor (clicking causes a check confirmation mode). A dropped terminal status is issued at a time of occurrence or check.
For a receptor with a check confirmation attribute, a status of a receptor with the smallest number is prioritized.
Video/image container: This has a function of receiving and reproducing videos, images, and audio data from a library data palette.
Arranged data is reproduced in sequence. The images are in a slide show. A simple still image is used for only one piece.
An accepted data category is determined by a category of data that has been dropped first.
In a user image, a still image is a frameless image.
In a video and slide show, a frame is placed outside the display part, and a control box for reproduction, stop, fast forward/rewind, and previous and next data is displayed by clicking the frame.
In the settings, defined viewing time and random reproduction are selected.
Defined viewing time: If set, a time input form appears to allow the time to be inputted. On the user side, the frame is emphasized when the defined time service is provided.
Random: If set, the order for playing changes randomly rather than as a sequence.
Receptor tab: There are three pieces, for two data receptors and a status emitter receptor.
For the data receptor, one type of data icon and data-type attribute can be dropped. The frame is initially for about five pieces, but expands when becoming full. This arrangement order is to be the reproduction sequence. For the inputted data, thumbnails are switched in sequence each time the thumbnail is clicked on the description form. Data that can be reproduced is reproduced by double clicking.
Data receptor 2 #External data usage
CSS data for paragraph decoration can be dropped.
Status emitter receptor
Still image: Successful loading/failed loading
Others: Complete reproduction/Reproduction/Exception/Successful loading/Failed loading/(Defined viewing time cleared)
Attribute input form: A form for a user to input an attribute value.
The same kind of forms can form an alternative selection group.
Types of input form
Text input: Character string
Select button: True/False ((List type character string can also be inputted for alternative selection group)
Check box: True/False
Numeric input form: Numeric value
Button: True/False
The user image is a form and a title.
The description form is a title input form.
Check confirmation property can be set.
Alternative selection group can be set.
Receptor tab
Attribute receptor (one piece)
Status emitter receptor
Successful reflection/input/exception
Data receptor #External data usage
CSS data for paragraph decoration can be dropped.
Attribute-specific description form: Participant-attribute-specific description is reflected in an arranged paragraph. The user image is a paragraph (maximum number of input characters).
The description form is a form in which an attribute name is written on a tab. Selecting the tab causes a form of a corresponding attribute and input details so far to be displayed.
Receptor tab
Multiple attribute receptors
When an attribute is dropped, a tab of the description form increases (determined as a true/false value in the transition control mode). In a case where multiple attributes apply, the sequence order of the attribute receptor is prioritized.
Data receptor #External data usage
CSS data for paragraph decoration can be dropped.
One form exists even if the attribute is blank. This converts the paragraph into screen parts.
External link description form: A link description form for an external URL. The user image is an underlined highlighted character string.
The description form is a character string input form (URL format check) for title input and URL input
Check confirmation property can be set.
Receptor tab
Status emitter receptor
Link selection
Data receptor #External data usage
CSS data for paragraph decoration can be dropped.
Status link description form: When clicked in the user image, a submit screen appears and a character string for making confirmation that the title has been selected is displayed (Highlight display after selection).
The description form is a title character string input form.
Check confirmation property can be set.
Alternative selection group can be set.
Receptor tab
Status emitter receptor
Submit
Data receptor #External data usage
CSS data for paragraph decoration can be dropped. #Transition control
Embedded cooperation object: An external module can be registered in this format in the library.
Specifications of the user image, the description form, and the receptor tab must be conformed.
External embedding form: Data for external embedding can be arranged. An embedded screen such as SNS is to be the user image. #External cooperation
https://dev.twitter.com/web/sign-inhttps://dev.twitter.com/ja/web/embedded-tweets, and the like
A status is issued when the link is selected or an operation such as reproduction is performed. #External data usage
Receptor tab
Status emitter receptor
Data receptor 1
A link destination description of an embedded description is dropped.
Data receptor 2
CSS data for paragraph decoration can be dropped.
Check button: A check button is a button of a unique image.
Specifications of the user image, the description form, and the receptor tab must be conformed.
Check button: A check button is a button of a unique image.
The user image is a button, click, and informing when dragging over.
The description form has a tab format including a character string input form for informing drag-over, unsatisfied condition click, and satisfied condition click. If there is no condition, the unsatisfied-condition click is not displayed.
Receptor tab
Status emitter receptor
Submit
Satisfied-condition click/Unsatisfied-condition click
Data receptor #External data usage
CSS data for paragraph decoration can be dropped.
Image and video upload form: A user can upload image and video data in the own terminal. A terminal for capturing is limited to a mobile phone or a smartphone, and image capturing time is also checked.
A default setting should be within a generation time of the relevant article. The time limit should be specified in the user image. It is possible to call a timing setting chart in the settings and make detailed designation. In that case, if the timing is not yet reached at that time, a display to that effect is shown in the user image.
For inputting to an attribute, arrangement is made in a receptor of a data-type scenario attribute.
#External data usage
Receptor tab
Status emitter receptor
Successful upload/Inappropriate data/Failed upload/Timing arrived
Attribute receptor (for data type)
Data receptor #External data usage
CSS data for paragraph decoration can be dropped.
Screen parts for special article: There are the following types.
The receptor tab is only for data receptor for paragraph decoration.
Participant type (see
Save recommendation attribute registration form: A list of recommendation attributes including attribute values, a select check box, and a submit button.
Two-dimensional barcode display parts: Two-dimensional barcode display, code display, and a code input form.
Two-dimensional barcode title display parts: Two-dimensional barcode title.
Emergency chat form: Chat window.
An article main part is sectioned into a user screen editing part and a box part.
The box part is a space where an emitter and modified data can be dropped for article transition control and screen configuration.
The user screen editing part is the same as a blog edit screen, and has a plain description palette and an editor.
A specification for plug-in of an existing blog editor is desirable. (It is desired to use a system used by a manager customer or an associate to be incorporated into the system. Example: This system is used as an additional service for editing articles on SNS).
Screen parts can be dropped on this edit screen, and an emitter can be dropped on a screen part arrangement part. Further, uploading of data is limited to be via a library of this system (process shortcuts may be incorporated).
Box part
Selection restraint box, check box: Described in detail in 3-3-5-3: Terminal status/check/selection restraint.
Article distribution completion box: When the article screen is fully loaded, a status arranged here is issued. Since the content generation is issued at a time of instance generation, the timing is slightly different.
Browsing end box: Browsing is ended when the article is closed, including external factors (tab deletion, exception occurrence). There is no reaction when the browser is simply closed, but reaction can be made possible also for closing of the browser by clicking the icon.
Modified data receptor: Modified data of the data palette can be dropped here. The modification can be checked in a preview of the user image.
By default, palettes are collected on a left edge of the screen, and an article main part occupies the other part. The palette itself is movable.
Palettes to be developed
Basic screen parts and screen parts imported from the library are stored.
Data registered in the library and having a format that can be used for screen parts is stored. For reflection, an import operation is required on the library side. The reflection is made by dropping in a data receptor of a screen part through DD. #External data usage
A normal attribute palette. Attributes that can be used in the scope are listed.
A normal status emitter palette.
Irregular occurrence selection: Clicking this causes highlight display, and sets classification to an article (canceled by clicking again). See 3-3-5-2: Article state transition #Content state control
Preview: The current user browsing screen is called. #Article description-User image conversion
Making variable and Fill-up: See 3-3-5-9: Forming template. When Making variable is clicked, the mouse pointer changes to a making-variable mode. It is canceled by clicking again. When Fill-up is clicked, a class is generated in a palette of a template definition module, and a transition is made to an edit screen.
See 3-3-1-2-1-1: Template and fill-up. #Class/template
Definition module change: Change is made by calling a content list (see
Created as a special article: A transition is made to 3-3-2: Scenario (main screen). A New creation tab for special articles is displayed on top.
Standardized library and private library: Described in detail in 3-4-5: Library. An ID of a transition source is assigned. #Library transition
To arrangement module: When clicked, a list of definition modules and arrangement modules appear. Selecting causes a transition to an edit screen.
In a template in articles, screen pats and attributes can be designated as variable icons. For the screen parts, each designated icon is individually recognized as a different class. In arrangement of multiple same attributes, designating one point causes all arrangements of attributes to become variable icons, and fill-up on one place is reflected in the same attributes.
As a special article edit mode, an article description screen is opened by a transition from a special article management block (3-3-2: Scenario (main screen)). A status emitter palette does not appear. Only participant attributes are displayed in the attribute palette.
Since the participant attribute becomes active after participation, display and input with use of the participant attribute is possible. Function is disabled before participation, and a message to that effect is displayed.
Since the selection part is arranged as a screen part, other parts can be edited. Status links cannot be arranged.
Since a code part is arranged as a screen part, other parts can be edited. Status links cannot be arranged. #Two-dimensional barcode page generation
In this screen, type information of a participant and a participant attribute are edited and applied to the type.
Participant attribute: A participant attribute is an attribute for managing attribute information apart from transition management of a scenario of a user, and described in detail in 3-3-1-3-4: Participant attribute.
Participant type (see
Binding
Manager ID
Scenario ID
Essential screen elements
Binding
Manager ID
Scenario ID
Participant attribute ID
Essential screen elements
Importable attributes
Setting is made as a save attribute, or a box that can be checked appears in a case of a synchronization type.
Binding
Manager ID
Scenario ID
Participant type (see
Essential screen elements
Binding
Manager ID
Scenario ID
Essential screen elements
There are items displayed with icons.
This is miniaturized to fit a height of list items. If there is more than one, display is overlapped and shaded. Clicking causes informing to appear, and the icons are arranged and displayed.
Message
Article
Nested normal module
Nested exception management
External module
External exception management
Calculation module
Condition module
Timing setting module
Attribute condition module
Classification field zone
Classification time zone
Template
Binding
Manager ID
Scenario ID
Essential screen elements
Binding
Manager ID
Scenario ID
Essential screen elements
See 3-4-5: Library. Checked contents are registered in the library.
There is used a mode for display control of a list by setting an affiliation relationship of modules as a tree tab in the content list (see
In a form hanging in a tree, each module displays directories of
The screen can be organized by opening and closing like a normal tree tab.
A scenario-unique two-dimensional barcode is generated on a page. When printing is performed, a scenario name and this code are printed.
There is also a code page generation button and a generation page list.
When the code page generation button is pressed, a page title input form appears. When input is performed on this, a two-dimensional barcode for printing and a code for inputting an outside trigger description module are generated and displayed. Further, this input code is registered in the library as data. #Library transition
When this page is printed, the title and the two-dimensional barcode are printed.
Pages generated so far exist in the generation page list.
Confirmation is made on check items while checking actual specifications.
Management of scenarios that have become operational events, (registered) participant management, save recommendation attribute management, and library management are performed.
A feasible scenario is a scenario object uploaded to a feasible scenario page after the outline check, and is actually put into a feasible state by giving settings. Further, at this time, it is also possible to perform a preliminary simulation by using a test simulation. For the scenario that in a feasible state, advertisement and starting can be performed on the page. The ongoing scenario is called an event.
The manager user can suggest a user to use points and titles given to the participant in own events in the past, in own events or disclosed events of other manager users. Users who agree after the event can save the attribute in their attribute holder, and manager users who can refer can use the attribute for their scenarios.
Binding
Manager ID
Essential screen elements
List
The participants mentioned here include
In a case of particularly specifying, referenceable user.
For these users, participation status in managed events can be monitored, and e-mails can be delivered at any time.
Binding
Manager ID
Essential screen elements
List
See
A participant attribute browsing screen of a participant is called. Attributes that can be referenced by the manager user are displayed.
Save recommendation attributes of own account
Disclosure setting attribute
Tag information of participants is also displayed.
Invitation: A user is to be in an invitation state when registered in an invitation list of an event in some way. This corresponds to a case of being listed in Invited event pickup!, being listed in available local entries, and receiving and checking an invitation e-mail.
Attribute condition achievement: Participant who has necessary participant attributes during the advertisement period (becomes a participant from here)
Event participating: Participant participating in the event
Left: Participant who has left the event
Finished: Participant who has finished the event
By pressing an invitation button, a scenario screen is called and a special article can be distributed to this user.
Binding
Manager ID
Essential screen elements
List
Out of list
Explanation: See
This is opened when use application has arrived for an own registration recommendation attribute.
Binding
Manager ID
Essential screen elements
List
A library is to store scenario materials that can be used by the manager user, and makes them available in all scenario creation (see
Reference context display: The library requires operations of storing checked contents in a reference source palette and setting as a definition module. Therefore, when a transition is made from a reference source screen, reference contents are bound to the operation, and a reference context is displayed on the screen.
The reference contexts are
Private library and standardized library: There are two types of libraries.
A private library is a library that temporarily stores derivatives and data materials created by the manager in scenario creation (see
Stored items of the private library are sent to a palette and classified.
A standardized library stores standardized contents, official and vendor external modules, and data.
Stored items of the standardized library are sent to a template palette as templates.
Temporal set at module download #Temporal search edit form: It is necessary to determine how to perform timing setting of a time zone and the like in the module.
A temporal search edit form is called, and editing is performed.
However, at this time, default processing is proposed. If an input request is reserved at this point, a blank trigger will be arranged instead (implementation as it is causes failure in the outer check).
Library data (see
Stored items
Contents
Template
Classified zone
Upload data
Screen part
Contents, templates, and classified zones are registered in the private library by designating and uploading a target from a contents list or an edit screen.
Template information for contents with a template is lost.
Download can be performed on the reference source by accessing the library with a reference context. The reference context is cooperated when accessed from the edit screen.
If the reference contents are a module, the module is set as a definition module, and if the reference contents are an article, a module to which the article belongs is set as a definition module. Data and screen parts only appear in the called edit screen.
3-4-5-2: Standardized Library #Class/Template #External Data Usage
Stored items
Template
External module
Additional screen parts
Official data
Download can be performed on the reference source by accessing the library with a reference context. The reference context is cooperated when accessed from the edit screen.
If the reference contents are a module template, the module template is set as a definition module, and if the reference contents are an article template, a module to which the article template belongs is set as a definition module. Additional screen parts and data can be referenced in scenarios.
Binding
Reference context
Essential screen elements
Explanation
When a category (extension) is designated from a list, file information of equipment is opened and selected. Uploading to the library is possible. Security check is performed to confirm that there is a format that can be registered.
3-4-6-1: Announcement e-Mail Delivery #E-Mail Delivery
An ad hoc sending e-mail address is issued that enables delivery of announcement notification e-mails to users with specific tags, save attributes, and histories. By delivering from a used e-mailer to the address, e-mails having the same information will be delivered to designated users.
Charges occur depending on the scale. Normal format e-mails are delivered.
An event monitor (see
Management of a manager trigger is performed either centrally on a manager trigger screen of the event monitor (see
There is also manager call means that allows direct communication with the manager in real time.
On the user side, with an action on the chart,
The manager call icon is enabled when a manager call icon is evaluated, and a chat screen is called.
The manager side can perform from a participant monitor at any time.
Emergency call can only be made by the manager side. WEBRTC is considered
It is made sure that both parties do not know phone numbers directly with the system interposed in between on the Internet.
Binding
Manager ID
(Scenario ID)
(Module ID)
A screen configuration of the chart monitor (see
Essential screen elements
Category
Arrangement content
Time zone
Field zone
Accompanying trigger
Trigger icon
Processing icon
Property part and Activity part appear in these icons. Moreover, a log marker described later can be arranged as a log receptor at a place where the conventional scenario attribute can be arranged.
Clicking the Property part causes details of the object to be displayed. (User's screen for documents, a module chart monitor for modules (see
Clicking the Activity part causes activity information to be displayed
In a case of an exception module, organizer call information can be browsed.
When a log marker is dropped on a log receptor, real-time monitor information of the location of dropping on a log monitor is displayed one after another.
Essential screen elements
Attribute activity is a list containing attribute values of a person having the attribute.
The Participant monitor displays a list of participants having individual instances. Clicking each participant name leads to selection of the corresponding participant, clicking a participant button at a lower part of the monitor causes a participant management screen to be displayed, and clicking a log icon causes a log to be displayed. Pressing Emergency response button causes a transition to an emergency response mode, and pressing Manager call button allows a manager call screen to be called.
In a log monitor, when an event occurs on an icon arranged with a log marker, a description of the event details occurs on the log monitor.
Essential screen elements
Log marker is an icon that is automatically-numbered when clicked. When arranged where arrangement is possible, it becomes possible to acquire information that can be browsed on the log monitor starting from the numbering.
Clicking the Log marker changes a mode, and drops the Log marker at the clicked position. #Log management
Emergency response marker appears when the chart monitor (see
The following can be performed.
Exception descriptions that operate in a certain scenario and all scenarios is monitored.
Biding
Manager ID
(Scenario ID)
Essential screen elements
A list of exception management within a range (each event or entire ongoing).
For a list order of exception modules, a priority order is determined by preferentially weighting the time most elapsed from the time when the manager call has occurred. Otherwise, the number of participants being processed is adopted.
Clicking a property causes display of an external module property screen (see
The activity is the same as the activity of the object in the chart monitor (see
If the manager call occurs in a service that may be included in the exception module, an exclusive chat can be made, and a call can be made from the manager side if necessary. The number of current occurrences is written, and a list of user names appears when clicked. When selected, a manager call is invoked.
Binding
Manager ID
Scenario ID
Exception management ID
User ID
Essential screen elements
Context information is displayed for 1 to 3
The participant log is similar to that of the Participant monitor.
Pressing the Emergency response opens a chart monitor (see
In the Emergency call, a call is made in a form where phone numbers of both parties are not known via the system.
In the Emergency chat, chat can be made with the chat that appears on the sub-screen of the user side.
Binding
Manager ID
Scenario ID
Essential screen elements
Explanation: see
A manager user membership category and the like are considered from an amount of data usage.
The following cases are assumed by the system as external cooperation.
web service
Embedding (embedding of other SNS tags)
Link
As an API usage format (a format for using external services such as guide services as a part of a scenario)
External module
Screen parts
As a target of API usage
Terminal app (management system)
External customer management, POS or venue location management system
External service
Route guide service
Context provision (weather forecast service, traffic information, and the like)
Entertainment (games, videos, interactive entertainment systems, and the like)
Data usage
Field zone definition data
Time of day/time data
Outside trigger (URL)/Scenario status/Entry trigger URL
Data for decoration (CSS)
Embedded data
AV data
Link destination data
Data for other external modules/Screen-parts correspondence data
Private and standardized libraries are integrated. Expansion of market functions in future is considered.
Registration data of the library can be selected to be disclosed or private.
In a case of disclosed, three modes: edit free, fixed, and internally invisible are selected.
A comment memo and a reference URL can be registered.
When downloaded to a palette of others, download points are given to the data.
Points will be given to the data when the embedded scenario is implemented.
If user evaluation is made after the implementation of the embedded scenario, this is also given.
An aggregated input form for template fill-up input is created.
A user screen of a terminal browser is designed in accordance with the use of
A screen configuration is adopted in which operation can be made with only a thumb in screen operations on a smartphone.
There are a mode transition and a display icon of a service screen having multiple display screens, navigations, and lists as display details.
Example: A distal end is assigned to a jump operation, and a middle part is assigned to movement.
Preparation is made for multilingual specifications.
#Scenario behavior
Regarding 1-4-2: Trigger/3-3-1-5: Descriptor (processing icon, transition arrow, and trigger icon)/3-3-1-6: Timing setting/3-3-4-3-1: Outside trigger description module/and 3-3-4-3-5: Scenario status receptor module, the following description is prioritized
A trigger icon, an outside trigger description module, and a trigger icon (on a timing setting chart) are organized and integrated into a control trigger and an outside trigger. Further, these two types of triggers are registered in a trigger palette and can also be used in a normal module (scenario) edit screen.
Control triggers are treated as processing icons same as TZs and the like, and outside triggers are treated as scenario level contents classes. An outside trigger incorporated into an imported module will be registered in a palette of any level. A manager trigger and a scenario status receptor are renamed at a time of import (an incorporated module name is added).
When a blank control trigger or outside trigger is arranged on a chart, a property edit screen is opened, and registration is made in the palette by inputting designated information.
Control trigger: A start trigger and a normal trigger of the trigger icon, and a trigger icon (on the timing setting chart) are here.
Property edit screen
None for Start (note that a start trigger and a transition from the start trigger can be omitted)
#Outline check
Numbering and memos for Normal
For the Timing, time is designated in accordance with the description in 3-3-1-6: Timing setting.
Outside trigger: This is changed from an external module to a trigger icon. 3-3-4-3-1: Outside trigger description module, manager trigger, 3-3-4-3-5: Scenario status receptor module are changed to this.
Property edit screen
See 3-3-4-3-1: Outside trigger description module and 3-3-4-3-5: Scenario status receptor module. For the Manager trigger, a unique name is registered in the scenario. Designation is made as to whether the multiple number of times or only one time is possible.
Displaying, Standby, Log P, Participating event, Invited event, and Event log can be identified by classifying tag colors and styles.
A search band is added to navigation
Search band display items
Persona-management-related common navigation: Displaying, Standby, Participating, Invited, Event log, Local entry
Started event common navigation: Displaying, Standby, Participating, Log P Post-participation event common navigation: Displaying (special P), Log P, Participating event, Invited event, Event log, Local entry
Other event common navigation: Participating event, Invited event, Event log, Local entry
Only checked targets are displayed
A display target of each P follows the transition in
Content list (see
Event list
Participation event contents list
For editing scenarios that have a relatively simple temporal structure and are highly dependent on geographical factors, or for checking geographical factors during creation of the normal screen, a map-type chart mode is added to the scenario and the nest type module edit screen. Both are shifted to each other by pressing the icon on the utility bar. See 3-3-1-4-4
Both have the same icon function except for some functions.
Screen configuration
Utility bar
Palette area
Map-type chart field
Sub chart window
Plain sub chart
Sub chart with FZ
Explanation: A utility bar and a palette area are same as those of the normal chart.
The map-type chart field is the map itself, and the map (chart field) scrolls with respect to the chart area. This similarly applies to the sub chart, and the chart scrolls (changes the scale) with respect to the chart window.
Icons can be individually arranged, and positions are fixed with respect to the chart, but only a transition arrow that crosses the chart changes a shape starting from a contact point with the icon or a window edge (an icon outside the window), in accordance with individual changes in relative positions of the window, the chart, and an FZ focus icon. (If both icons in the same chart are outside the window, the arrow disappears)
Where to specify as the start point in the window edge is determined based on which of a center of four sides or corners is closer to the icon outside the window.
A scroll bar is arranged on the window frame.
The map chart is a chart on which a map or a field object is placed. Only an area and a focus icon of a field zone have geographical meaning in information on the map (a distance and movement information between focus icons are also displayed). In other arranged icons, only a transitional relationship has meaning (it is possible to move a position for easy viewing and grasping the relationship). In this mode, the field zone can only be arranged on the map chart.
Clicking highlight on the utility bar can change display to a normal map and a blank map.
When a distance arrow is provided between the focus icons, a guide module is called on a property setting screen, and route information is calculated. Selecting a route causes display of a distance and a required time at the distance arrow.
The plain sub chart has a see-through mode in which an icon is displayed on the map in accordance with the window by an amount of a relative position change (only the scroll bar is displayed), in addition to normal mode, which follows the above limitations, of being arranged in a chart window whose position is fixed relative to the screen. Which is to be applied can be selected at the time of arrangement or in settings.
The field object is an object having an image with position information, FZ information set thereon, and contents information (connection information). The map object has a class added with map coordinate information, and the block field object has block information for sectioning an image and connection information for between blocks. The block and the connection information can have property information that enables description of relationships. Further, it is also possible to have a method to output relationship information between designated elements.
It is also possible to apply limitations as a sub chart.
A sub chart with FZ is a chart arranged in a sub chart window whose position is fixed with respect to the map chart. It is associated with the FZ and is developed and stored in the vicinity by clicking the FZ focus icon. A transition arrow of a stored icon is provided with the focus icon as a start point. All icons arranged on the sub chart with FZ belong to that FZ.
This chart is created as a child class of the map chart. If it is inclusive, it is possible to further add an FZ within the FZ. The arrangement of contents is not limited to the FZ area.
Field zone: An FZ is arranged on the map chart similarly to 3-3-1-4-3-2: Range setting. The field zone icon disappears temporarily when arranged on the map, and a point marker appears.
When the setting is finished, a range display, a focus icon, and an accompanying trigger appear. The focus icon is immovable in a case of a point, and can freely move within a range in a case of the range. The sub chart with FZ appears in the periphery by clicking, and disappears by clicking again. By providing a distance arrow on another focus icon, the guide module can be called.
Time Zone: In this mode, a time zone has an associator icon and an affiliation time zone icon, and an instance can be arranged on each of the sub charts (if there is a nested relationship, information of the TZ in the bottom layer is displayed).
Arrangement can be made normally on any sub chart from the palette.
An instance is created by dragging from an associator, or dragging from the palette if classified, and dropping on a chart where no instance is arranged. Further, when dropped on an icon, an affiliation time zone icon is caused at the place (which functions as an instance, and disappears when entering the TZ of the same class).
By D-click on the associator, all other than the TZ and the icons belonging to the child TZ seem to have disappeared.
Individual instances can send and receive transitions, but their functions do not change depending on the position (a function for organizing the appearance).
This instance is only for the appearance, unlike the instance that is arranged in a separate module by classification.
Free focus icon: This icon is stored in the processing palette only in this mode, and can be arranged on the map chart only for route calculation. A function is similar to that of the focus icon in the field zone.
Distance arrow: This icon is stored in the processing palette only in this mode, and can be arranged on the map chart only for route calculation. Only between focus icons can be connected.
Icon movement between modes: Icons that are already arranged on each chart when switching is made between modes are shifted in accordance with the following rules. After that, the arrangement other than the FZ and the TZ can be freely changed (across sub charts), and information is retained even after being shifted and returned again.
Normal chart to map type: An icon with an affiliation FZ is shifted to a corresponding sub chart with FZ while maintaining a mutual positional relationship (if there is a TZ, an affiliation time zone icon is added). Other icons will be shifted to a plain sub chart while maintaining a mutual positional relationship, and existing TZs are also shifted here.
From the map type to the normal chart, arrangement is made in a blank part inside the frame of the affiliation TZ (in a plain sub chart if there is no blank part). If the frame is too small for arrangement, the entire frame moves downward and the frame expands.
As described above, in the map-type user interface, not the time zone but the field zone is structured and managed with the inclusion relationship.
As described above, the time zone and the field zone can be structured by using both or one of the zones.
When a simple process is modularized for some reason, it is necessary to open an edit screen and perform processing involving screen transition in order to see processing in the module. In order to prevent deterioration of browsability in this case, a nest type module is equipped with a window function similar to the function of the sub chart window in the map type. The function of the window is the same as that of the sub chart window, but it is necessary to switch to the edit screen for editing (because palette details are different).
A mechanism for checking a transitional relationship of a chart at any time during scenario development is incorporated, for checking estimated time when an event ends or temporal consistency.
In a case of incorporating this mechanism, the chart has the following limitations.
An external transition expected time element is also calculated with transition information in the target zone (a receptor and a trigger are also given)
Restriction calculation is a calculation for extracting a set of participant attributes of reference-only or having range information for a target zone, and a transition sequence that enables transitions under exception exclusion/irregular exclusion conditions.
Objects that can be target zone: TZ, nested module (scenario)
Objects that can be comparison zone: content, in addition to the above
Comparison zone: An object that has an internal logic such as internal transition, and expected time information based on external transition information in the target zone. Consistency of both is not promised.
Further, focusing on the status, a transition sequence caused from exception and irregular statuses, and exception management and a subsequent transition sequence are excluded. In a case of merging into another transition, the transition to that node is excluded.
The impossibility test is conducted while focusing on each comparison zone to achieve solution.
Transition sequence: This is obtained by developing a transitional relationship of a certain target zone by using a transition arrow and systematic trigger information, into a directed acyclic graph (DAG) having only one vertex of 0th order input.
Note that, if all the route calculations are difficult due to a calculation amount, temporal optimization can be performed by a route extraction simulation or the like of performing divisions of the target zone through hidden module automatic setting and depth-oriented search trials as many times as possible. In this case, it is also possible to improve efficiency of the simulation by linking a restriction condition with a search target (for example, in restrictions including exceptions, a trial that targets the exception module is prioritized, or an attribute determination element is targeted).
By performing this operation for all comparison zones in the range, all transition sequences are converted into transition sequences from module start and TZ time-in
#This disassembly does not extend to a hidden module and an inside of an article, but ends with replacement of an accompanying trigger and a timing setting.
A node that is not connected to time-in at the end and is generated by a transition from outside
An affiliation relationship of the FZ is performed, by adding a transition conditional counter to transitions to TI and TO.
Regarding time-out, a transition from inside remains as it is (cutoff is inhibited for internal transition (because the path is to be closed at replacement of the next section))
Transitions outside the target zone disappear (transition timing information is lost if there is no standard range information)
Since the expected time range can be reduced, replacement is made with a transition conditional counter. However, if a transition from outside the target zone is determined, replacement is made with the out-of-zone trigger.
Expected time calculation is performed by setting an inside of a loop as a target zone, and expected time calculation is performed by setting an affiliation TZ as a target: Smaller one of an affiliation TZ longest expected time/In-loop shortest time and a determination value is to be the maximum number of loops (a margin may be added). Note that the calculation target zone is increased by one level in a case where the longest expected time of the affiliation TZ or the module is divergent (o) without being limited by the determination value. If the restriction of the affiliation TZ or the module does not occur until the end, a warning is given, and the process is stopped or input of a constant or an upper limit time of the scenario is requested.
Disassembly of a multi-transition from the status of the hidden module and article is treated according to a setting, if any, or as a short transition if there is no setting.
As a setting of a status of the elements described above
Restriction
Expected time addition element (for each in-element transition)
The number (for multi-transition)
#In a case of a multi-transition, an expected time element is attached to each.
For example, if the maximum number of loops in A is 3, development is made as follows (a single transition starts from a branch on top/multi-transition on bottom)
A multi-transition outflows other than the counter is disassembled for each route.
Expected time composition is performed with the transition sequence unchanged See $ Expected time composition
Disassembly is performed at a time of expected time composition.
None of them can confirm true or false from a transition sequence
(A time series cannot be confirmed. Consideration is required for processing when the time series can be confirmed with a counter and the like)
Note that, for functions of the scenario attribute of the transition control mode, similar functions can be realized even with a transition arrow by creating a counter having a negative or inversion sensing function, or increasing the number of transition arrows
(However, unique replacement is not possible (which means that description by the manager is possible). Since the path is not shared, it is not always possible to determine true or false. Then, the number itself of transitions has already been increased)
When a node is deleted and the element becomes a terminal, the terminal is supplemented.
Objects that can be target zone: TZ, nested module (scenario)
Objects that can be focal zone: content, FZ, in addition to the above
It is determined by an arrangement relationship between with a target zone.
Start trigger
Internal arrangement trigger
/External arrangement (normal trigger, child module trigger, passing transition arrow)
This is determined by an inclusion relationship between a reference module and a target zone
A certain time calculation transition sequence forms a directed acyclic graph (DAG) made up of elements connected by directed transition arrows originating from a start trigger. Among connecting points with the transition arrow of the element, the one for receiving is called a receptor, and the one for sending called a trigger, which form a DAG made up of transition arrows and in-element directed transitions that connect all the receptors and triggers of a certain element. The receptors and triggers at this time are called nodes.
Note that a timeless element simply forms one node.
A set of expected time when a certain transition sequence (up to a node) ends at the shortest and expected time when the transition sequence ends at the longest.
In addition, a range of the most likely end time.
A certain in-element directed transition can have an addition element related to expected time. It takes a form of an added value to an element of each expected time, where
Shortest time<=Longest time
Standard shortest<=Standard longest
must be satisfied.
(+MN+MX) (+MNs+MXs)/+MN
+MX
+MNs+MXs
For details, see $ Element category expected time addition element.
Expected time of a final terminal (a node connected to a termination receptor of a target zone) and expected time of a termination receptor, in following a transition sequence of the target zone
Expected time from a start trigger of the transition sequence to any receptor or trigger (node).
Shortest time Longest time
Standard shortest Standard longest
(MN MX) (MNs MXs)/
MN MX
MNs MXs
When there are multiple transition arrows flowing into a node, a set of shortest and longest expected times (MN MX) is composed. See Simple counter composition.
Merging node
A node having an outflow of a single transition other than a counter is regarded as C=1.
(The smallest of the inflow shortest and longest values is adopted)
The value is the same even if there are multiple outflows
An impossibility test with range information of an expected time set (MNS MXS) of a start trigger and a termination trigger (MNF MXF), in a comparison zone.
Impossible if MXF<MNS.
Complete establishment if MXS<=MNF.
An expected time range of a termination trigger is composed to (MNF/MNS|MNF<MNS MXF/MNS|MXF<MNS).
The shortest time of a counter that receives C times of transition where N>=C from N pieces of input arrow is set as the maximum value obtained by sorting the shortest value of transition arrows in ascending order and adopting C pieces.
A normal timeless node has a C value of 1.
The longest time of a counter that receives C times of transition where N>=C from N pieces of input arrow is set as the maximum value obtained by sorting the longest value of transition arrows in ascending order and adopting C pieces.
A normal timeless node has a C value of 1.
In a case of a multi-transition, the maximum value is obtained from adopted N×C pieces by disassembling into a quotient obtained by dividing the number of inputs by the number of counters, and individually sorting values of the second and subsequent times.
When C is a range, the minimum of the maximum value of individual C values in the range is adopted for the shortest time. The maximum of similar C value maximum value is adopted for the longest time.
If determined transition expected time does not exist, a value of a conditional transition is used.
Impossible if MN<MX<MNc. For (Y/N) branching, only N is left as a transition path.
Complete establishment if MXc<=MN<MX. For (Y/N) branching, only Y is left as a transition path.
Expected time for Y transition (positive value transition) is (MN/MNc|MN<MNc MX/MNc|MX<MNc)
Expected time for N transition is (MN/MXc|MXc<=MN MX/MXc|MXc<=MX)
In a case of a dependent trigger, a trigger that receives determined with a generation trigger as a condition is adopted.
Sequence calculation is performed by performing expected time composition.
See $ Expected time composition
The internal transition is developed to be a part of the chart.
After primary calculation is ended
$ Focus comparison zone inside/outside transition check
is performed, to verify consistency of the internal transition and the external transition (in a case where all the inner transitions in the comparison zone are aggregated to the termination trigger (or are caused to be aggregated), the check ends at the first calculation).
A trigger for which when to occur cannot be predicted from range zone information. If there is no designation, (+0 +∞) (+0 +∞) is set.
A start trigger of the target zone. (0 0) (0 0) is set. A start GTM can be inputted for global time relativization.
A trigger that simply causes time elapse. (+X +X) (+X +X)|X is a designated value
A specific fixed time is set as a trigger. Inputting the start GTM to the start trigger leads to a simple addition trigger, otherwise to an undefined trigger.
Expected time addition information for each termination state is given. This is information according to internal logic from generation to a termination trigger occurrence.
In a case where the object is designed to take into account a transition to a normal receptor, it is necessary to designate whether a status property is a merging node, a simple counter, or a transition conditional counter.
It is also possible to retain for each status, but it is restricted by the overall information. If not designated, (+Z +∞) (X Y)|X, Y, and Z are system-defined values for the icon.
Consistency check is performed between internal processing of a module and a TZ, which are a framework for temporal management of events, and temporal restrictions from outside such as life-time settings.
In each of MNI MXI and MNX MXX
MNSI MXSI and MNSX MXSX
instead of the start trigger
an impossibility test is conducted using each internal transition value.
See $ (Simple) Impossibility test of comparison zone
When there are multiple comparison zones that can be checked, a zone (in which an external transition does not depend on other unverified comparison zones) on upstream of the transition sequence is prioritized.
For comparison zone having no unverified comparison zone inside, the inside/outside transition check can be performed as a focus comparison zone.
When a transition arrow comes out from a certain FZ trigger to the inside of the target zone, a movement time calculation arrow can be led to a trigger where another FZ transition arrow comes out.
Replacement is made on expected time due to a transition of the target trigger, by adding the expected time time addition information based on guide calculation, to expected time of the outgoing trigger.
The original transition is regarded as a start trigger, and the impossibility test is performed on the action time calculation arrow.
See $ (Simple) Impossibility test of comparison zone
By using a verification scheme of $ Focus comparison zone inside/outside transition check
As with between FZs, an action time calculation arrow can be simply led from a certain trigger or receptor to a trigger or a receptor in another target zone.
The manager inputs required time information at this time.
Addition may be performed in the shortest and longest and/or the standard range. The original value remains for a value not added. (In a case where the actual transition sequence is not sequentially connected or the like, it is safer to not use the shortest and longest, or to pass through a transition unless it is completely restricted physically such as movement)
In
An embodiment in which a field type module is added will be described below with reference to
By standardizing, to a slot type, processing of a module that provides each service that is to be a component of an event and has location and time range fixed eventually, it is possible to further simplify the event creation. This enables various utility processes.
An overall structure will be described with reference to
A field performs processing of an event by arranging a child module called a field unit in a slot of the edit screen.
The field can have an aspect of either an overall processing module or an individual processing module. Further, it is also possible to become a unit for execution of other fields as an attraction.
The field unit is categorized into: an attraction that performs processing with time and a location specified (functions of the field are specialized for controlling modules with specified time and location, although unspecified ones are also possible); a control module (that may be integrated with the field) that performs processing of the field; and a utility (that may be integrated with the field) that adds specific functionality to the processing of the field. Further, the field unit uses a specific slot.
Control types provided by the control module include: a stage that executes attractions in time order (scheduled time can be designated); a stamp rally where attractions are arranged at specific points (location attractions); a tour that has a generation order (with scheduled time) in location attractions; a maze that designates a generation condition and an order for each attraction; and other processing. There are three categories of control properties: interrupt designation, delay management, and optimum route calculation. Details are shown in
The stage type executes attractions within a range of a time restriction in the order of slot numbers. The delay management is performed when it is determined that a specific attraction is inexecutable due to time designation of each attraction. In addition, parallel implementation of attractions is not possible, and slot numbering is used.
As for the tour type, attractions are executed in the order of slot numbers. The end of the previous number is to be a condition for start condition standby of the next attraction. In addition, parallel implementation of attractions is not possible, and slot numbering is used.
The stamp rally type executes an attraction when a start condition for the attraction is satisfied. Multiple attractions cannot be implemented in parallel. In addition, parallel implementation of attractions is not possible, but slot numbering is not used.
For the maze type, an attraction is executed when a start condition of the attraction is satisfied. A control #tag is issued that designates the order between attractions and feasibility of parallel implementation. Further, whether or not parallel implementation of attractions is possible is designated by the control tag, and slot numbering is not used.
As control detail,
In the interrupt designation, when the designation is made by a type subjected to slot numbering, a generation trigger occurs independently for the designated attraction, and the designated attraction is implemented after a normal attraction being executed is interrupted or ended. Another control tag is issued.
When the designation is made by a type without slot numbering, the attraction is excluded from optimum route calculation. The ongoing attraction is interrupted or implemented.
Final attraction designation: The field ends when the attraction executed by the control tag with this designation ends.
In the delay management, when the designation is made by a type subjected to slot numbering, a generation trigger occurs independently for the designated attraction, and the designated attraction is implemented after a normal attraction being executed is interrupted or ended. Another control tag is issued.
When the designation is made by a type without slot numbering, the attraction is excluded from optimum route calculation. The ongoing attraction is interrupted or implemented.
Final attraction designation: The field ends when the attraction executed by the control tag with this designation ends.
In the optimum route calculation, excluding attractions subjected to the interrupt designation in a control type not subjected to the slot numbering, a route search is performed based on movement time, and an optimum route is calculated. Further, if there is a time restriction, possible combination of attractions with a time restriction is made as a case-classification calculation, a route search is performed for each of the time-designated attractions (in the route calculation of the later section, attractions used in the previous calculation are excluded), and all the results are compared to regard a route with the shortest time to be optimum.
The calculation time may be shortened by relaxing the condition instead of the entire result.
A control flow of the control module is as shown in a lower part of
Note that, for the attraction start condition, a simple condition can be selected (control in which attribute restriction is applied only with a participant attribute, and a timing setting is not used (triggers and conditions are independent)>All generation management is performed by an internal behavior of control M. If there is a control module that requires a simple condition, this setting is adopted, and selection of a mode of the attribute restriction and the time restriction is limited).
Conversely, a dependency relationship may be analyzed from a marker arrangement that controls transition arrows and transitions, and an order condition may be incorporated into the control.
See
A control module slot is a slot in which a palette field unit can be arranged. A slot position that can be arranged differs depending on a type of a unit. Multiple units can be arranged in an attraction slot and a utility slot. (extending downward)
Attraction slots are numbered for each slot. This numbering (ranking of markers) may be realized by markers or tags that require arrangement to clearly indicate positions and orders of slots even if they are not explicit (excluding attractions subjected to interrupt designation). Rearrangement may be performed automatically.
A unit #tag form is a form for editing tag information of a field unit arranged in a slot. A unit internal tag is extracted and displayed, and a control tag is written. Internal tags cannot be edited here. By inspecting this, the control module performs control.
For the control types and the properties, setting is made for a control type, a control property, a utility-provided property, and a field (internal setting) restriction, and the control #tag is displayed on the form.
The utility-provided property is a property setting form of a utility arranged in a slot of a field. Properties closely related to control can be controlled here.
A control #tag is a tag for the control module to specify and manage attractions and utilities. Arrangement is made on the tag form. See
Further, the role of the control tag may be realized by a graphic marker.
Time, a location restriction, and an attribute restriction are forms for editing internal restrictions. There are one for a field, one for each attraction, and one for a utility. See
The attribute restriction is for performing a member restriction of the corresponding module. An interface is the same as that of the member restriction part.
The time restriction is for a time restriction of the corresponding module. The time restriction works the same as a time zone subjected to time-in and time-out in an absolute time range at the time of implementation. Setting can be made with six modes in order to make confirmation at the time of implementation, in consideration of conditions for restrictions based on details of attractions and modules and of conditions set individually by the manager.
Control module management is a mode in which the control module performs an optimum time range based on category information of the attraction, without detailed designation on the attraction side.
Arrangement time zone-Required time designation is a mode for designating a recommended time required for that attraction as a required time, and designating a time zone that can be arranged with the time, with absolute time designation, day of the week, or daily time zone information. This does not have to be designated on both sides. In that case, non-designation is handled similarly to the control module management.
Absolute time designation is a mode for designating attraction start time and timeout time in absolute time.
List designation is a mode for designation by a list of multiple absolute time designations or arrangement time zone-Required time designations.
Data/attribute arrangement is a mode to perform designation with a value of an arranged graphic object.
Timing setting is a mode for arranging a timing setting unit.
The location restriction is for a location restriction of the corresponding module. At the time of implementation, the time restriction works the same as a field zone subjected to range designation. Setting can be made with five modes in order to make confirmation at the time of implementation, in consideration of conditions for restrictions based on details of attractions and modules and of conditions set individually by the manager.
The control module management is a mode in which the control module performs an optimum location designation based on category information of the attraction, without detailed designation on the attraction side.
Arrangement range-Shape designation is a mode for designating a size and a shape of a location required for the attraction, and designating a range in which the location can be arranged. This does not have to be designated on both sides. In that case, non-designation is handled similarly to the control module management. By a map tile designation type confirmation process of a control module attraction arrangement flow and a listing process of a location range information, list designation is to be resulted.
FZ designation is a mode for designating a specific field zone.
List designation is a mode for designation by a list of multiple FZ designations or arrangement range-Shape designations. Data/attribute arrangement is a mode to perform designation with a value of an arranged graphic object.
Individual conditions are designated through four methods (5 to 6 modes) of: absolute designation; designation of a definite value that can be controlled from a range/list by the control module; external conditions (data indefinite designation) with attributes and library data; and complete management with the control module. The method in which the control module finally confirms is called control indefinite designation.
Status trigger/receptor, attribute (data) receptor: Attractions and utilities can be equipped with an icon corresponding to a status trigger/receptor and an attribute (data) receptor of a module, in order to control individual behaviors. Details are determined by internal description of the attraction.
There are four types: a status trigger, a status receptor, an attribute receptor, and a library data receptor, and the same interface as the equivalent functional part of the module (FIG. C-2,
Reserved (attribute) receptor/trigger and free (attribute) receptor System control object
A reserved (attribute) receptor/trigger is a receptor/trigger used by the control module, and is occupied by the control module. It is not possible to arrange an attribute or set an end point of a transition arrow (emitters can be arranged). Which receptor is to be reserved is determined, for each control module, by a status and a receptor, and numbering of an attribute (data) receptor (attractions and utilities must be designed to meet functional specifications required by the control module).
Further, there is also an object that is used for behavior management of attractions and utilities and prepared by the system. This is a non-display control object, and corresponds to generation, transition non-generation, forced termination, affiliation field zone, and affiliation time zone.
A free (attribute) receptor is for a person who edits, to designate details of operation of utilities and attractions by using receptors/triggers where transition arrows, attribute icons, and emitters can be arranged. This must be prepared in advance with an attraction or utility.
Designation of these reserved (attribute) receptors/triggers and free (attribute) receptors is determined by category information of the attraction. On the basis of the category information, the control module and the utility are processed in association with numbering information reserved by status emitter/status trigger logic of each status or trigger, but may be identified with order information or reservation name information of the receptor or the trigger.
Transition arrow, emitter, attribute (data)
Transition arrows and emitters can be arranged and connected in several places on the edit screen.
Transition arrow start point: All statuses on the screen
Transition arrow end point: Trigger except reservation and timing setting on the screen
Status emitter: All statuses, triggers, and timing settings on the screen Attribute emitter: All arranged attribute icons
Attribute (library data) icon: Attribute receptor and attribute restriction except reservation
Attraction internal editing
Details of an attraction can be edited by opening an internal edit screen. An attraction type module is provided with a sub edit screen so as to enable internal editing of a location restriction and a time restriction (the sub edit screen is integrated into a property setting screen for an external module, and called from a setting bar for a nest type).
Further, an attraction introduction module can be designated (the module can be called regardless of restrictions (designated by a transition from status trigger 1).
Utility internal editing
A property of a utility can be edited by calling an internal property setting screen. The editing mutually reflects editing of control module properties.
Palette
There are certain limitations applied on a palette arrangement object of a field.
Content palette: field unit, attribute condition module, timing setting module
Attribute Palette: No limitations
Processing palette: Normal transition arrows only
Status emitter palette: No limitations
Library data palette: If a data receptor other than reserved is arranged, corresponding data is arranged
Main utilities will be explained.
A future timeline can be displayed as a timeline or a list while the utility arrangement field is being implemented (standby is possible), by extracting estimated attraction start time information and related information of child fields arranged as fields and attractions. Further, a related service is performed. In timeline/list display, as a user service page or page collection, an attraction title and an edited comment are displayed as a timeline or a list (when there is no start time information). By selecting a part (selecting a tab), an introduction module is called. (A partial timeline can be mixed and displayed, if any)
A tree shape may be adopted if parallel processing is possible or if mutual interruption is set (partial TL display showing connection information)
In the partial timeline, a timeline may be partially established by user's designation, a part of a maze and the like, or passed attraction information. The start time is displayed if specified, otherwise time display is performed on the time from the starting point of the first attraction of the TL.
In an alarm setting, when an attraction (or start, end, and the like of a field) is designated as an alarm target, the alarm is performed by tracing back to the designated time from the estimated attraction start time information. A page displayed with the highest priority is called. Further, if a delay (additional difference of end time) during regular scanning is more than a certain time, a delay warning is also given.
Implementation attraction selection is a function for a participant to designate an attraction to be implemented or prioritized/subordinated from a timeline/list. When this is done, estimated attraction start time information is recalculated in accordance with the selection of the participant.
<<Note>> It is also possible to extract a display transition sequence of a module designated by some means in expected time calculation, by using logic such as regular, shortest, middle, longest, and the like, and use the start time as the estimated attraction start time information.
Guide provides a guide for movement on the timeline, and movement to a designated attraction and a designated point from the current location. Further, behavior management is performed on an arranged normal guide module as a related module, to manage so that a plurality of guides do not start at the same time. Within the attraction zone, a normal guide is prioritized.
Movement time presentation provides (adds to the timeline/list and displays) movement time information from the current location to attractions arranged in fields and child fields.
Passed attraction information presentation provides the control module with passed attraction information in a case where a recommended movement route in a field where there is no timeline or all routes have passed through a zone of a specific attraction. The passed attraction information is used as a partial timeline when usage settings are made.
Utility point guidance performs guidance to a designated point selected under a specific condition from a utility point list of a specific category arranged on the map. When the designated point is confirmed, it is registered as an interrupt attraction and incorporated into the time line and route calculation. Further, the utility point guidance can also be associated with a specific attraction, and upon arrival, that attraction is called with the designated point as a location zone. The attraction is designated by an issued control #tag. The designated point may be determined from a group of optimum conditions with a distance, a movement time, user selection, or the like.
As for a service screen call M (related M), a designated point designation screen is called when a screen call M arranged in the attraction is selected.
As for the designated point, a designation method is performed either based on a point that has the shortest movement time and conforms a condition, or on participant designation. Further, whether it is emergency or not can also be set, and interruption is made immediately after in a case of emergency, otherwise the designated point will be optimized and incorporated into the timeline.
Group management M groups multiple participants, and provides utilities necessary for a group action. A grouping attraction of the utility interrupts at the beginning of the field to perform grouping of the participants in a designated way.
In an attraction call condition setting, attraction call and ending conditions can be set in detail in relation to group processing. Selection setting can be made from four types: All, First arrival, Fixed rate designation, and Lost designation exclusion.
In lost processing, at a time of position scanning, members with a certain distance or more or deviations thereof from a barycentric position of the group, or from a member designated as a leader are designated as lost. When the number of lost designations exceeds a certain ratio, a status confirmation screen is sent to confirm the lost processing target or to temporarily divide the group. When the divided groups gather within a certain range, joint confirmation is performed. Further, for lost, emergency response module/utility/attraction can be called if designated. A dedicated page is called. In the above processing, lost designation (all distances or deviations from the barycenter), and group division can be performed by performing cluster analysis based on position coordinates of group participants, and calculating a plurality of group members in the group and barycenter. The cluster analysis may also be used at the time of initial grouping to present estimated groups.
A web stage (live stream) generates a web page for live stream viewing corresponding to the event. Acquisition of information is performed by arranging two related modules in the attraction. On the page, events, acquired information, and participants can be evaluated.
An uploader (related module) sends data acquired by a participant terminal, associated recording equipment, and the like, to a stream page.
Participant evaluation display is a module that creates a page that presents evaluation information on the web page to the participants. The participant evaluation display is arranged in the attraction to provide the page to the user.
Web data cooperation is a utility that acquires information generated by a web system for delay management and information presentation, and provides in a form of attributes and library data. Information is transferred using a free attribute receptor. Train timetable information, and check-in information for shops and the like are exemplified.
Future timeline display, utility point guidance, and group management can be extracted as technical matters in the present invention.
This is a module that automatically calculates and manages a start or an expected start time of each location event by a management program, by specifying a location event management module to standardize the location and time limit information.
This enables delay management, recommended route setting, future timeline display, and the like.
Overall processing will be described with reference to
Targets of a member scope have been sorted into individual description targets and instances to organize a class structure of the overall processing and facilitate description of interactions. Further, an incorporation method has also been changed.
Indication of Individual description target in an interaction body defines that a participant and some equipment are set as a processing target as participants of the process. The individual description target is managed and driven by an individual description in a middle part of the figure. The entities of the individual description are an individual description time zone and an individual description module. The individual processing target is incorporated as a member scope into an overall description describing an interaction aspect, to perform interaction. Management of the interaction is performed with an overall processing attribute in which an instance, a key described later, or a member of the member scope is an attribute value holding target.
An interaction field is where the relationship is described. The overall description is handled by an overall processing time zone and an overall processing module.
A behavior of the description is defined by an interaction aspect in the figure. The description of the interaction is arranged in the overall description as illustrated in Generalization in an upper part in which individual descriptions that describe a behavior of members in the member scope are nested, and different descriptions are assigned depending on attributes, types, and transitions of members. Moreover, in order to describe interaction between specific members, a sub overall description is assigned with a more limited member scope and described.
What the individual description reflects in the interaction is expressed in several aspects in the middle part.
Mutual descriptions between the extracted and limited members are carried out with an overall processing attribute that is used to extract the member scope and bring a value generated at an individual place to an upper level.
Overall processing attribute: A behavior of an overall processing attribute and a behavior of a key that secures a transaction of the interaction are described in
As shown in
Whereas, an overall processing attributes are categorized into three types, which are: a member scope attribute having an individual description processing target that is a member of a certain member scope, as an attribute value holding target; an instance-type attribute having a key or an instance (when key is not defined) as an attribute value holding target; and a group-type attribute. The group type has a form for holding a member scope different from that of the instance type, and constituent members of the member scope with different keys and instances do not overlap.
Reference of attribute information differs depending on a zone in which the attribute icon is arranged. As described in a center of
The overall processing attribute can have member information described in
Key: A key is a code that is for transaction identification, and is assigned to some members and instances of an overall processing attribute. An attribute can hold multiple keys, and a member scope is defined for each. In addition to the individual processing target, the key can also hold an instance as a member scope. A key structure in
A key is issued by conformance or a certain description arranged on a trigger receptor. Details are described in Arrangement on trigger/receptor and MS and key at time of attribute conformance, in
Further, by performing instance generation transition based on an overall processing transition that is restricted by the attribute holding the key or that holds the key, through a connector or a normal overall transition, the generated instance is incorporated into the instance member scope of the key. See
In a description of the incorporated instance, processing can be performed on the member scope that belongs to the key as a target. In an instance description and an individual description of an individual description body, processing unique to the member scope can be performed by using an attribute value related to the key. In a lower part of
Transition processing using key and overall processing:
On the right in
A method for automatically generating a key for transaction (session) processing of interaction at the time of event processing by arranging an icon at an appropriate position in the graphic that represents the transition, or a method for confirming a target that uses the key are a technical matter characteristic of the present invention.
In a new article specification, a change has been made to adopt a format that is based on editing with an html editor, and have control tags inserted there. The specification is described in
The html description is made in the editor on the left, and a tag corresponding to an emitter is generated or the emitter is composed in a form in a center.
The form has a fix check box, a generation status selection, a form, a status icon generation check, and a comment field.
By performing generation status selection by a pull-down and the like, and selecting a mode of the form, fix becomes possible. When the fix is done, the next form (block) appears. See
In addition, in the form, an html tag for embedding appears, or a status arrangement box appears if a status is composed.
The status corresponds to an issue status of the article, but control can be performed on whether to be displayed as the status on an article icon.
In composing the status, a generation status is issued when any one or all of the arranged status icons are selected.
An attribute emitter corresponds to data import used in an input form or display data on the screen, a script, or the like.
Further, an icon of the generation status in the form can be dragged and dropped, and can be arranged in the status arrangement box.
It is possible to adopt a method of using an icon to easily generate a link or a tag for data transfer in the HTML editor (dependent on the status emitter in the next section, as the claims).
A status of a module by a status emitter and an attribute receptor are generated.
There are four types of emitters that can be arranged in the module. These are a regular status emitter, an irregular status emitter, an attribute tab argument emitter, and an attribute tab return value emitter. See
A status emitter arranged in a trigger/receptor generates a status on a module icon. An attribute tab emitter arranged in a scenario attribute of a transition mode generates an attribute receptor tab that allows arrangement of a scenario attribute on an icon. Tabs include an argument tab and a return value tab, the argument tab assigns an arranged attribute value to an internal scenario attribute at a time of transition evaluation, and the return value tab assigns to the arranged attribute value at the time of internal transition evaluation.
A method of graphically setting event processing inside and outside a module, an argument, and a return value is a technical matter characteristic of the present invention.
In order to simplify range designation and reduce a calculation amount at the time of implementation, a change has been made to adopt a method to reduce a calculation amount by setting a tile region designated in advance in a map, associating a participant terminal subjected to current location measurement with a specific tile, and recalculating only when the tile moves.
Range designation: Range designation of a field zone is performed by designating polygonal tiles that fill the map. The figure shows designation of a rectangular tile with a part shifted horizontally. A general relationship is maintained by adjusting a shift length without changing a tile area depending on the latitude.
A range is specified by designating a tile from an FZ range setting screen where the tile is displayed.
Standard tile and effective tile: When there is a problem with accuracy of a geodetic system, and in order to reduce a calculation amount, it is possible to set an effective tile that is larger than a standard tile designated by a user. Actual location tile registration is performed with the effective tile. Effective tiles may be prepared in multiple types. In order to reduce a frequency of recalculation, coarse ones are used when an F zone of a participation event is distant, and fine ones are used when approaching. (A change may be made depending on a participant type)
Range determination of an FZ uses a determination range of execution tiles covering a designated range of the standard tiles.
Location tile identification: Position information is acquired at regular intervals to identify a location tile.
Based on the location tile information, field-in/out determination is made every time there is a change, and a distance to a cluster of a field zone active in an event is calculated.
A size of the effective tile and a location scanning time interval are adjusted in accordance with a result of the distance calculation. This reduces the calculation amount.
The distance calculation may be calculation from normal latitude/longitude, such as forming an axis between representative points such as a barycenter, a major axis, and a median value of an azimuth diameter, and setting, as an effective distance, a distance from an on-axis projected position of the nearest range end or from coordinates of the range end. Alternatively, for example, it is also possible to calculate an approximate value by calculating the number of interval tiles (for example, through limitation of a route search direction or settings of the same distance tiles with respect to a specific direction) from characteristics related to orientation of polygonal tile arrangement.
In addition, in order to minimize fluctuation of the location tile, a margin is set in a periphery, and the location tile is not changed if position information is acquired within that range. The number of times of this processing may be limited.
A method of reducing the calculation amount by performing the location tile registration processing and the event processing tile designation for the participant position information processing is a technical matter characteristic of the present invention.
The specification has been changed as shown in
From the requirements of the claims, improvement has been made to remove a scroll management icon (landing pages that combine a list of tabs and a page are mutually shifted, and an oblique or fan-shaped transition bar (of a pulling-down type that scrolls in that direction) is used. This is a technical matter characteristic of the present invention.
For output and input of an interpretation structure, it is possible to use a markup language, or a data description language that can describe a structure by nesting, or that can describe an object structure such as JavaScript object notation (JSON). In this case, notation of an object corresponding to a zone including a description is set, and list information indicating a nesting structure or an affiliation relationship is added.
About Level 2 advanced management method
This system can also be applied to traveling in parties, a group tour, tour guiding organized by travel agencies (see
As shown in
This is a continuation in part application of U.S. patent application Ser. No. 17/281,771 filed on Mar. 31, 2021 which is national stage of PCT international application number PCT/JP2018/048118 filed on Dec. 27, 2018, the disclosure of which are incorporated herein by reference.
Number | Date | Country | |
---|---|---|---|
Parent | 17281771 | Mar 2021 | US |
Child | 18948397 | US |