特表 2024-536546 計算論理の処理方法、電子デバイス及び読み取り可能な記憶媒体

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公表特許公報(A)

(11)【公表番号】

(43)【公表日】2024-10-04

(54)【発明の名称】計算論理の処理方法、電子デバイス及び読み取り可能な記憶媒体

(51)【国際特許分類】

   G06F 15/82 20060101AFI20240927BHJP

【ＦＩ】

G06F15/82 620Z

【審査請求】有

【予備審査請求】未請求

(21)【出願番号】P 2024523130

(86)(22)【出願日】2022-09-01

(85)【翻訳文提出日】2024-04-17

(86)【国際出願番号】 CN2022116538

(87)【国際公開番号】W WO2023065847

(87)【国際公開日】2023-04-27

(31)【優先権主張番号】202111211756.7

(32)【優先日】2021-10-18

(33)【優先権主張国・地域又は機関】CN

(81)【指定国・地域】

(71)【出願人】

【識別番号】523073389

【氏名又は名称】エバオテック コーポレーション

(74)【代理人】

【識別番号】110001416

【氏名又は名称】弁理士法人信栄事務所

(72)【発明者】

【氏名】ニー，ジアン

(72)【発明者】

【氏名】ション，フェイ

(72)【発明者】

【氏名】ワン，ユンテン

(72)【発明者】

【氏名】リュウ，ジュンシェン

(72)【発明者】

【氏名】シン，ジーフェイ

(72)【発明者】

【氏名】モー，ヤンウー

(57)【要約】

本願はコンピュータソフトウェア分野に関し、計算論理の処理方法、電子デバイス及び読み取り可能な記憶媒体を開示する。本願が提供した計算論理の処理方法は、サーバ側及びクライアント側を含む電子デバイスに用いられ、該方法において、クライアント側は、入力データ及びコンフィギュレーションデータを取得してサーバ側に送信し、サーバ側は、コンフィギュレーションデータを解析し、静的計算サブグラフを生成し、入力データと静的計算サブグラフとを接続して動的計算サブグラフを生成し、最後に、動的計算サブグラフを実行して計算結果を得ることによって、計算論理と入力データとのデカップリングを実現し、計算論理の再利用を実現し、ソフトウェア開発者の開発効率を高めることができる。また、計算論理は、独立した方式で実現、構成、管理及び動作を行うことで、計算論理の実現での誤りがアプリケーションモジュールとは無関係になるようにして、アプリケーションモジュールのメンテナンサビリティを高めた。
【選択図】図１

【特許請求の範囲】

【請求項1】

サーバ側及びクライアント側を含む電子デバイスに用いられる計算論理の処理方法において、
前記クライアント側は、計算論理を実行するために必要なデータ値を記述するための入力データと、業務処理中の前記計算論理の配置情報及び前記計算論理の間の関連情報を記述するためのコンフィギュレーションデータを取得してサーバ側に送信することと、
前記サーバ側は、前記コンフィギュレーションデータを解析し、静的計算サブグラフを生成し、前記静的計算サブグラフが前記計算論理をノードとし、前記計算論理の間のデータ流れ方向を辺とすることと、
前記サーバ側は、入力データと静的計算サブグラフとを接続し、動的計算サブグラフを生成することと、
前記サーバ側は、前記動的計算サブグラフを実行し、計算結果を得ることと、を含むことを特徴とする計算論理の処理方法。

【請求項2】

前記サーバ側は、前記コンフィギュレーションデータを解析し、静的計算サブグラフを生成することは、
前記サーバ側は、階層構造を有する計算論理をシリアライズすることと、
前記サーバ側は、シリアライズ結果に基づいて静的計算サブグラフを生成することと、を含むことを特徴とする請求項１に記載の方法。

【請求項3】

前記サーバ側は、シリアライズ結果に基づいて静的計算サブグラフを生成することは、
前記サーバ側は、フローベースプログラミング技術により、シリアライズ結果に基づいて静的計算サブグラフを生成することを含むことを特徴とする請求項２に記載の方法。

【請求項4】

前記サーバ側は、入力データと静的計算サブグラフとを接続し、動的計算サブグラフを生成することは、
前記サーバ側は、前記静的計算サブグラフにおける計算論理のデータパラメータに基づき、前記入力データにおいて対応のデータ値を決定して前記データ値を前記データパラメータに接続することを含むことを特徴とする請求項１に記載の方法。

【請求項5】

前記サーバ側は、前記動的計算サブグラフを実行し、計算結果を得ることは、
前記サーバ側は、前記動的計算サブグラフを実行し、初歩的な計算結果を得、前記コンフィギュレーションデータのうちのフォーマット配置情報に基づいて前記初歩的な計算結果をフォーマット処理し、フォーマット後のデータを得て、前記計算結果とすることを含むことを特徴とする請求項１に記載の方法。

【請求項6】

前記計算論理は、少なくとも計算式、拡張関数、変数、フィルタ、決定木のうちの１つを含むことを特徴とする請求項１に記載の方法。

【請求項7】

前記入力データのフォーマットは、ＪＳＯＮ形式であり、前記コンフィギュレーションデータは、ＹＡＭＬとＤＳＬとの組み合わせにより記述されることを特徴とする請求項１に記載の方法。

【請求項8】

電子デバイスにおいて、
電子デバイスの１つ又は複数のプロセッサにより実行される命令を記憶するためのメモリと、
電子デバイスのプロセッサの１つであり、請求項１～７のいずれか１項に記載の計算論理の処理方法を実行するためのプロセッサと、を備えることを特徴とする電子デバイス。

【請求項9】

読み取り可能な記憶媒体において、前記読み取り可能な記憶媒体に命令が記憶され、該命令が電子デバイスにおいて実行されると、電子デバイスに請求項１～７のいずれか１項に記載の計算論理の処理方法を実行させることを特徴とする読み取り可能な記憶媒体。

【請求項10】

コンピュータプログラム／命令を含むコンピュータプログラム製品において、該コンピュータプログラム／命令がプロセッサにより実行されると、請求項１～７のいずれか１項に記載の計算論理の処理方法を実現することを特徴とするコンピュータプログラム製品。

【発明の詳細な説明】

【技術分野】

【0001】

本願は２０２１年１０月１８日に中国特許局に提出された、出願番号が２０２１１１２１１７５６．７であり、出願の名称が「計算論理の処理方法、電子デバイス及び読み取り可能な記憶媒体」である中国特許出願の優先権を主張し、その全ての内容は、援用によって本願に組み込まれる。

【0002】

本願は金融ソフトウェアの分野に関し、特に、計算論理の処理方法、電子デバイス及び読み取り可能な記憶媒体に関する。

【背景技術】

【0003】

現在、オンライントランザクション処理の分野においてもビッグデータ処理の分野においても、データ処理プロセスで使用される計算論理、例えば計算プロセス、計算ルールや計算式などはあるプログラミング言語による符号化によって実現されることが多く、符号化方式で計算論理を実現することは、計算論理開発者への要求が高い。また、異なるデータ処理アプリケーションにおける同じ計算論理の実現は多種多様であり、データ処理アプリケーションのメンテナンスにとって不利である。

【0004】

保険業務の分野において、ある組み合わせ計算論理は割に複雑であり、例えば、その中、決定木計算、四則演算、集約計算や計算条件ルールなどのような多種の計算論理を含み、組み合わせ計算論理の演算ステップもルールに応じて変化する可能性があり、ひいては論理組み合わせ計算論理の演算プロセス、例えば新たな保険商品を新規作成しているうちに新たな計算論理などを新規作成する必要があり、これらの複雑な組み合わせ計算論理を符号化することには、開発の難易度が高く、作業効率が低いという問題が存在する。

【発明の概要】

【0005】

本願実施例は、従来技術において計算論理がアプリケーションモジュールに密結合され、かつ符号化によって実現される必要があるという問題を解決するための計算論理の処理方法、電子デバイス及び読み取り可能な記憶媒体を提供する。

【0006】

第一の態様によれば、本願実施例はサーバ側及びクライアント側を含む電子デバイスに用いられる計算論理の処理方法を提供する。該方法は、
クライアント側は、計算論理を実行するために必要なデータ値を記述するための入力データと、業務処理中の計算論理の配置情報及び計算論理の間の関連情報を記述するためのコンフィギュレーションデータとを取得してサーバ側に送信することと、
サーバ側は、コンフィギュレーションデータを解析し、静的計算サブグラフを生成し、静的計算サブグラフが計算論理をノードとし、計算論理の間のデータ流れ方向を辺とすることと、
サーバ側は、入力データと静的計算サブグラフとを接続し、動的計算サブグラフを生成することと、
サーバ側は、動的計算サブグラフを実行し、計算結果を得ることと、を含む。
上記第一の態様による可能な実現において、サーバ側は、コンフィギュレーションデータを解析し、静的計算サブグラフを生成することは、
サーバ側は、階層構造を有する計算論理をシリアライズすることと、
サーバ側は、シリアライズ結果に基づいて静的計算サブグラフを生成することと、を含む。

【0007】

上記第一の態様による可能な実現において、サーバ側は、シリアライズ結果に基づいて静的計算サブグラフを生成することは、
サーバ側は、フローベースプログラミング技術により、シリアライズ結果に基づいて静的計算サブグラフを生成することを含む。

【0008】

上記第一の態様による可能な実現において、サーバ側は、入力データと静的計算サブグラフとを接続し、動的計算サブグラフを生成することは、
サーバ側は、静的計算サブグラフにおける計算論理のデータパラメータに基づき、入力データにおいて対応のデータ値を決定してデータ値をデータパラメータに接続することを含む。

【0009】

上記第一の態様による可能な実現において、サーバ側は、動的計算サブグラフを実行し、計算結果を得ることは、
サーバ側は、動的計算サブグラフを実行し、初歩的な計算結果を得、コンフィギュレーションデータのうちのフォーマット配置情報に基づいて初歩的な計算結果をフォーマット処理し、フォーマット後のデータを得て、計算結果とすることを含む。

【0010】

上記第一の態様による可能な実現において、計算論理は、少なくとも計算式、拡張関数、変数、フィルタ、決定木のうちの１つを含む。

【0011】

上記第一の態様による可能な実現において、入力データのフォーマットは、ＪＳＯＮフォーマットであり、コンフィギュレーションデータは、ＹＡＭＬとＤＳＬとの組み合わせにより記述される。

【0012】

第二の態様によれば、本願実施例は電子デバイスを提供する。該電子デバイスは、
電子デバイスの１つ又は複数のプロセッサにより実行される命令を記憶するためのメモリと、
電子デバイスのプロセッサの１つであり、上記第一の態様及び第一の態様による可能な実現のいずれか１つの計算論理の処理方法を実行するためのプロセッサと、を備える。

【0013】

第三の態様によれば、本願実施例は読み取り可能な記憶媒体を提供し、読み取り可能な記憶媒体に命令が記憶され、該命令が電子デバイスにおいて実行されると、電子デバイスに上記第一の態様及び第一の態様による可能な実現のいずれか１つの計算論理の処理方法を実行させる。

【0014】

第四の態様によれば、本願実施例は、コンピュータプログラム／命令を備えるコンピュータプログラム製品において、該コンピュータプログラム／命令がプロセッサにより実行されると、上記第一の態様及び第一の態様による各種の可能な実現のいずれか１つの計算論理の処理方法を実現することを特徴とする。

【0015】

本願実施例が提供した計算論理の処理方法は、サーバ側及びクライアント側を含む電子デバイスに用いられ、該方法において、クライアント側は、入力データ及びコンフィギュレーションデータを取得してサーバ側に送信し、サーバ側は、コンフィギュレーションデータを解析し、静的計算サブグラフを生成し、それから、入力データと静的計算サブグラフとを接続して動的計算サブグラフを生成し、最後に、動的計算サブグラフを実行して計算結果を得ることによって、計算論理と入力データとのデカップリングを実現し、計算論理の再利用を実現することができ、ソフトウェア開発者の開発効率を高めることができる。また、計算論理は、独立した方式で実現、構成、管理及び動作を行うことで、計算論理の実現での誤りがアプリケーションモジュールとは無関係になるようにして、アプリケーションモジュールのメンテナンサビリティを高めた。

【図面の簡単な説明】

【0016】

【図1】図１は本願の幾つかの実施例によれば、計算論理の処理プロセスを示している場面模式図である。

【図2】図２は本願の幾つかの実施例によれば、幾つかの計算論理の実例を示している模式図である。

【図3】図３は本願の幾つかの実施例によれば、電子デバイスのハードウエアの構成を示している図である。

【図4】図４は本願の幾つかの実施例によれば、計算論理の処理方法を示しているフローチャートである。

【図5】図５は本願の幾つかの実施例によれば、入力データのフォーマットを示している模式図である。

【図6】図６は本願の幾つかの実施例によれば、保険料金を計算するためのコンフィギュレーションデータの実例を示している模式図である。

【発明を実施するための形態】

【0017】

本願の例示的な実施例は、計算論理の処理方法、電子デバイス及び読み取り可能な記憶媒体を含むが、これに限定されるものではない。

【0018】

本明細書で使用されるように、用語「モジュール」は、専用集積回路(ＡＳＩＣ)、電子回路、１つ又は複数のソフトウェア又はファームウエアプログラムを実行するプロセッサ(共有、専用、又はグループ)及び／又はメモリ、組み合わせ論理回路、及び／又は記述された機能を提供する他の適切なハードウェアコンポーネントを指し又は含んでもよく、又はこれらのハードウェアコンポーネントの一部としてもよい、と理解されたい。

【0019】

本願の各実施例において、プロセッサは、マイクロプロセッサ、デジタル信号プロセッサ、マイクロコントローラ等、及び／又はそれらの任意の組み合わせであってもよい。他の態様によれば、前記プロセッサは、シングルコアプロセッサ、マルチコアプロセッサなど、及び／又はそれらの任意の組み合わせであってもよい、と理解されたい。

【0020】

本願の計算論理の処理方法は、多種の計算論理からなる計算論理フローを計算する場面に適用される、と理解されたい。

【0021】

以下、図面を参照しながら、本願の実施例についてさらに詳しく記述する。
図１は、本願の幾つかの実施例によれば、多種の計算論理からなる計算論理フローを計算する場面を提供する。図１に示すように、ユーザ１００は、入力データ及びコンフィギュレーションデータをアプリケーションモジュール２００に提供し、アプリケーションモジュール２００は、入力データ及びコンフィギュレーションデータを受信して計算エンジン３００に送信して計算し、計算エンジン３００は、計算後に得られた計算結果をアプリケーションモジュール２００に返し、アプリケーションモジュール２００は、返信された計算結果に基づいて後続処理を行ったり、ユーザ１００に提示したりする。

【0022】

計算論理（Ｃｏｍｐｕｔａｔｉｏｎａｌ Ｌｏｇｉｃ，ＣＬ）とは、業務アプリケーションにおいて業務機能を実現するために必要な計算に関する要素を指し、計算プロセス、計算ルール、計算式等を含んでもよいが、これらに限定されない。具体的に言えば、幾つかの基本的な計算論理には、例えば計算式、拡張関数、変数、フィルタ、決定木等がある。計算論理には、通常、データパラメータが含まれ、計算論理は、データパラメータの代入に基づいて計算を行い、具体的な計算論理結果を得る。

【0023】

ユーザ１００は、ソフトウェアアイテムの業務に慣れている者であってもよいし、プロのソフトウェア開発者であってもよく、ユーザ１００は、準備した入力データとコンフィギュレーションデータとをアプリケーションモジュール２００に提供する。ここで、入力データは、具体的なデータ値であり、計算論理におけるデータパラメータの代入値として用いられる。コンフィギュレーションデータは、多種の計算論理を含む複雑な業務処理プロセスを配置するためのもので、多種の計算論理の関連配置情報やデータパラメータなどを含み、コンフィギュレーションデータには、計算論理の具体的な計算に用いられるデータ値が含まれていない。コンフィギュレーションデータと入力データとの分離は、計算論理と入力データとのデカップリングを実現することができることによって、業務処理プロセスの再利用を実現し、同じ業務処理プロセスの繰り返し開発を避け、ソフトウェア開発者の作業効率を向上させることができる。

【0024】

アプリケーションモジュール２００は、ユーザ１００が提供する入力データ及びコンフィギュレーションデータを取得するためのものであり、取得方式は、様々な方式を採用してもよい、インターフェース方式で取得すること、ファイル形式で取得すること、ユーザの選択に応じて取得することなどを含んでもよいが、これらに限定されない。例えば、アプリケーションモジュール２００は、ユーザ１００に入力データインターフェース及びコンフィギュレーションデータインターフェースを提供し、ユーザ１００は、入力データインターフェースとコンフィギュレーションデータインターフェースとで関連データの入力を行い、ユーザ１００による入力が完了した後、入力データインターフェース及びコンフィギュレーションデータインターフェースは、ユーザが入力したデータをアプリケーションモジュール２００に提出してもよい。ユーザ１００は、予め入力データとコンフィギュレーションデータとをデータファイルに記憶しておき、データファイルをアプリケーションモジュール２００に提出し、アプリケーションモジュール２００は、データファイルを解析することで入力データ及びコンフィギュレーションデータを得てもよい。アプリケーションモジュール２００は、ユーザ１００に複数の予め設定されたコンフィギュレーションデータテンプレートを提供して、ユーザ１００が選択したコンフィギュレーションデータテンプレート又は修正されたコンフィギュレーションデータテンプレートを、使用するコンフィギュレーションデータとしてもよい。

【0025】

アプリケーションモジュール２００は、入力データ及びコンフィギュレーションデータを取得した後、入力データ及びコンフィギュレーションデータを計算エンジン３００に送信して計算を行う。計算エンジン３００は、多種の計算論理に対して抽象化処理を行い、入力データをコンフィギュレーションデータに定義された計算論理に代入して計算して計算結果を得てもよい。計算エンジン３００が処理する入力データは、異なるデータ構造を含んでもよく、階層構造、リスト構造等を含んでもよいが、これらに限定されない。

【0026】

図２は、計算エンジン３００がサポート可能な幾つかの計算論理の実例を示しており、Ｌｉｓｔ（リスト）、Ｉｔｅｍ（リストアイテム）、Ｆｉｌｔｅｒ（フィルタ）、Ｄｔｒｅｅ（決定木）、Ｖａｒ（変数）、Ｅｘｐｒ（式）等を含み、ここでの式の計算論理は、ｍａｘ（最大値）、ｍｉｎ（最小値）、ｓｕｍ（合計）、ｓｕｍｉｆ（条件に一致する数値の合計）、ｒｏｕｎｄ（丸め）等の関数計算論理をさらに含んでもよい。ユーザ１００は、コンフィギュレーションデータにこれらの計算論理のうちの１つ又は複数を用いてもよく、複数の計算論理を用いる場合には、コンフィギュレーションデータにおいて複数の計算論理を計算論理フローの形式に構成してもよい。

【0027】

最後に、計算エンジン３００は、計算論理の計算結果をアプリケーションモジュール２００に返し、アプリケーションモジュール２００で後続処理を行う。アプリケーションモジュール２００は、計算結果を後続処理の入力データとしてもよく、直接ユーザに計算結果を提示してもよい。

【0028】

本願の技術手段が提供する方法は、単独に設置された計算エンジン３００上で計算論理を含むコンフィギュレーションデータと入力データを実行し、元々複数のアプリケーションモジュール２００に分散されている計算論理を計算エンジン３００上に集中して実行することを実現し、計算エンジン３００で計算論理の演算をまとめて実現し、ソフトウェア開発者がアプリケーションモジュール２００毎に計算論理を繰り返し実現する必要がないことによって、ソフトウェア開発者の仕事量を減少し、ソフトウェアアプリケーションの開発効率を高めた。また、計算エンジン３００により計算論理の実現と実行をまとめて管理することで、ソフトウェアアプリケーションのメンテナンサビリティを高めた。計算論理の実現にはエラーが存在する場合には、計算エンジン３００に修正するだけで、修正後の正確な実現を複数のアプリケーションモジュール２００に応用することができることによって、アプリケーションモジュール２００のメンテナンスが便利になる。

【0029】

図３は、本願の幾つかの実施例によれば、計算論理の処理方法を実現するための電子デバイス３０のハードウエア構成を示すブロック図である。図２に示す実施例において、電子デバイス３０は、１つ又は複数のプロセッサ３０１と、プロセッサ３０１のうちの少なくとも１つに接続されたシステム制御論理３０２と、システム制御論理３０２に接続されたシステムメモリ３０３と、システム制御論理３０２に接続された不揮発性メモリ（Ｎｏｎ-Ｖｏｌａｔｉｌｅ Ｍｅｍｏｒｙ, ＮＶＭ）３０４と、システム制御論理３０２に接続されたネットワークインターフェース３０６とを含んでもよい。

【0030】

幾つかの実施例において、プロセッサ３０１は、１つ又は複数のシングルコア又はマルチコアプロセッサを含んでもよい。幾つかの実施例において、プロセッサ３０１は、汎用プロセッサ及び専用プロセッサ（例えば、グラフィックプロセッサ、アプリケーションプロセッサ、ベースバンドプロセッサ等）の任意の組み合わせを含んでもよい。電子デバイス３０が増強型ベースステーション（Ｅｖｏｌｖｅｄ Ｎｏｄｅ Ｂ，ｅＮＢ）又は無線アクセスネットワーク（Ｒａｄｉｏ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ，ＲＡＮ）コントローラを採用している実施例において、プロセッサ３０１は、様々な該当する実施例を実行するように構成されていてもよい。例えば、プロセッサ３０１は、計算論理の処理方法を実行するために用いられてもよい。

【0031】

幾つかの実施例において、システム制御論理３０２は、プロセッサ３０１のうちの少なくとも１つ及び／又はシステム制御論理３０２と通信する任意の適切なデバイス又はコンポーネントに任意の適切なインターフェースを提供するように、任意の適切なインタフェースコントローラを含んでもよい。

【0032】

幾つかの実施例において、システム制御論理３０２は、システムメモリ３０３に接続されたインターフェースを提供するように、１つ又は複数のメモリコントローラを含んでもよい。システムメモリ３０３は、データ及び／又は命令をロード及び記憶するために用いられてもよい。例えば、システムメモリ３０３は、本願実施例において計算論理を解析する命令をロードしてもよいし、入力データやコンフィギュレーションデータなどを保存してもよい。

【0033】

幾つかの実施例において、電子デバイス３０のシステムメモリ３０３は、任意の適切な揮発性メモリ、例えば、適切なダイナミックランダムアクセスメモリ（Ｄｙｎａｍｉｃ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ，ＤＲＡＭ）を含んでもよい。

【0034】

ＮＶＭメモリ３０４は、データ及び／又は命令を格納するための１つ又は複数の有形の、非一時的なコンピュータ可読媒体を含んでもよい。幾つかの実施例において、ＮＶＭメモリ３０４は、フラッシュメモリ等の任意の適切な不揮発性メモリ及び／又は任意の適切な不揮発性記憶デバイス、例えば、ハードディスクドライブ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ，ＨＤＤ）、コンパクトディスク（Ｃｏｍｐａｃｔ Ｄｉｓｃ，ＣＤ）ドライブ、デジタルバーサタイルディスク（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｃ，ＤＶＤ）ドライブのうちの少なくとも１つを含んでもよい。本願実施例では、ＮＶＭメモリ３０４は、アプリケーションモジュールによって取得された入力データ及びコンフィギュレーションデータを記憶するために用いられてもよい。

【0035】

ＮＶＭメモリ３０４は、電子デバイス３０が実装される装置上の一部の記憶リソースを含んでもよいし、又はデバイスによってアクセスされてもよいが、必ずしもデバイスの一部であるとは限らない。例えば、ネットワークインターフェース３０６経由でネットワークを介してＮＶＭメモリ３０４にアクセスしてもよい。

【0036】

特に、システムメモリ３０３及びＮＶＭメモリ３０４は、命令３０５の一時コピー及び永久コピーをそれぞれ含んでもよい。命令３０５は、プロセッサ３０１のうちの少なくとも１つにより実行されると、電子デバイス３０が図３に示す方法を実施するようにする命令を含んでもよい。幾つかの実施例において、命令３０５、ハードウエア、ファームウエア及び／又はそのソフトウェアコンポーネントは、システム制御論理３０２、ネットワークインターフェース３０６及び／又はプロセッサ３０１に追加的に設置／代替的に設置されてもよい。

【0037】

ネットワークインターフェース３０６は、電子デバイス３０に無線インターフェースを提供するためのトランシーバを含んでもよく、さらに、１つ又は複数のネットワークを介して任意の他の適切なデバイス（例えばフロントエンドモジュール、アンテナ等）と通信を行う。幾つかの実施例において、ネットワークインターフェース３０６は、電子デバイス３０の他のコンポーネントに集積されてもよい。例えば、ネットワークインターフェース３０６は、プロセッサ３０１の、システムメモリ３０３、ＮＶＭメモリ３０４、及び命令を有するファームウエアデバイス（図示せず）のうちの少なくとも１つに集積され、プロセッサ３０１のうちの少なくとも１つが前記命令を実行すると、電子デバイス３０は、方法の実施例に示す方法を実現してもよい。本願実施例では、ネットワークインターフェース３０６は、アプリケーションモジュールから送信された入力データ及びコンフィギュレーションデータを受信するために用いられてもよい。

【0038】

ネットワークインターフェース３０６は、多入力・多出力無線インターフェースを提供するように、任意の適切なハードウエア及び／又はファームウエアをさらに含んでもよい。例えば、ネットワークインターフェース３０６は、ネットワークアダプター、無線ネットワークアダプター、電話モデム及び／又は無線モデムであってもよい。

【0039】

幾つかの実施例において、プロセッサ３０１のうちの少なくとも１つは、システムインパッケージ（Ｓｙｓｔｅｍ Ｉｎ ａ Ｐａｃｋａｇｅ，ＳｉＰ）を形成するように、システム制御論理３０２のための１つ又は複数のコントローラの論理と一緒にパッケージしてもよい。幾つかの実施例において、プロセッサ３０１のうちの少なくとも１つは、システムオンチップ（Ｓｙｓｔｅｍ ｏｎ Ｃｈｉｐ,ＳｏＣ）を形成するように、システム制御論理３０２のための１つ又は複数のコントローラの論理と同一のダイに集積されてもよい。

【0040】

電子デバイス３０は、入力／出力（Ｉ／Ｏ）デバイス３０７をさらに含んでもよい。Ｉ／Ｏデバイス３０７は、ユーザと電子デバイス３０とのインタラクションを可能にするユーザインターフェースを含んでもよい。周辺コンポーネントインターフェースの設計により、周辺コンポーネントも電子デバイス３０とインタラクションすることができる。
図３に示される構造は電子デバイス３０の具体的な限定を構成するものではないと理解されてもよい。本願の他の幾つかの実施例では、電子デバイス３０は、図示よりも多い又は少ない部品を含んでもよいし、幾つかの部品を組み合わせたり、幾つかの部品を分割したり、異なる部品で配置をしたりしてもよい。図示された部品は、ハードウエア又はソフトウェア、或いはソフトウェアとハードウエアとの組み合わせによって実現されてもよい。
以下、上記図３に示す構造を参照して、図４に基づいて具体的な場面と結びつけて、本願の技術手段を詳しく紹介する。図３に示すように、本願の幾つかの実施例では、計算論理の処理方法の技術手段は、以下のステップを含む。

【0041】

Ｓ４０１：クライアント側は、サーバ側に入力データ及びコンフィギュレーションデータを提供する。
クライアント側は、計算論理を演算するための入力データ及びコンフィギュレーションデータを取得するために用いられ、クライアント側は、ソフトウェアアプリケーションにおけるモジュール又はコンポーネントであってもよい。サーバ側は、クライアント側から送信された入力データ及びコンフィギュレーションデータを受信して、入力データ及びコンフィギュレーションデータに基づいて、相応の計算論理の演算を行い、計算結果を得るために用いられる。サーバ側とクライアント側に対応するハードウエアデバイスは、電子デバイス３０であってもよい。

【0042】

本願の幾つかの実施例では、ユーザ１００は、クライアント側に入力データ及び対応するコンフィギュレーションデータを同時に提供してもよいし、クライアント側に入力データのみを提供して、コンフィギュレーションデータがクライアント側によって生成されてもよい。ここで、クライアント側は、様々な方式でコンフィギュレーションデータを生成してもよい、例えば、クライアント側は、予め開発されたコンフィギュレーションデータテンプレートをそのまま使用してコンフィギュレーションデータを生成してもよいし、ユーザ１００によるコンフィギュレーションデータテンプレートへの修正結果に基づいてコンフィギュレーションデータ等を生成してもよい。

【0043】

また、クライアント側は、ユーザ１００に対して相応の入力インターフェース及び配置インターフェースを提供することで、ユーザ１００による関連データの入力を容易にしてもよい。入力インターフェース及び配置インターフェースは、グラフィカルインターフェースであってもよいし、さらに、関連データの入力プロセスにグラフィカルな案内プロセスを提供してもよい、これによってユーザ１００に入力データ及びコンフィギュレーションデータの入力を完了させるように案内し、入力プロセスでエラーが発生する可能性を減少することができる。

【0044】

本願の幾つかの実施例では、入力データのフォーマットは、多種の形式を有してもよいし、ＸＭＬ形式、ＪＳＯＮ形式等を含んでもよいが、これらに限定されない。クライアント側は、ユーザ１００が提供する入力データを受信した後、入力データをクライアント側に使用される統一のデータフォーマットに変換してもよい、例えば、ユーザ１００が提供する入力データのフォーマットは、ＸＭＬ形式であり、クライアント側は、入力データをＸＭＬ形式からＪＳＯＮ形式に変換してもよい。クライアント側は、入力データのフォーマットを直接使用してもよく、例えば、ユーザ１００が提供する入力データのフォーマットはＪＳＯＮ形式であり、クライアント側は、ＪＳＯＮ形式の入力データをそのまま使用してもよい。

【0045】

図５は本願の幾つかの実施例における入力データのフォーマットの例示を示す。図５に示すように、［ｋｅｙ］は、入力データにおける１つの具体的なデータパラメータの名称を表し、データパラメータの名称は、任意の文字列を用いて記述してもよく、例えば、１つのデータパラメータの名称が「ｕｓｅｒｎａｍｅ」である。ここで、データパラメータは、コンフィギュレーションデータにおける同名のデータパラメータに対応し、入力データにおけるデータパラメータに対応するデータ値は、計算論理の演算プロセスにおいてコンフィギュレーションデータにおける同名のパラメータに代入するために用いられる。［ｖａｌｕｅ］は、データパラメータに対応するデータ値を表し、該データ値が任意の文字や数字からなる文字列であってもよい。

【0046】

入力データには、複数のデータパラメータ及び対応するデータ値が定義されてもよい。図５において、“…”：“…”の形で表される。ｉｔｅｍｓは、入力データ中のキーワードであり、入力データにおける階層構造で組織されたデータを記述するために用いられる。ｉｔｅｍｓにおける［ｉｄ］は、１つのｉｔｅｍを表す唯一の標識であり、唯一の標識により対応するｉｔｅｍを決定することができ、該唯一の標識は、任意の文字や数字からなる文字列であってもよい。ｉｔｅｍｓにおける［ｋｅｙ］、［ｖａｌｕｅ］の意味は、上記意味とほぼ同じであり、異なるところは、作用の範囲が異なることにあり、ｉｔｅｍｓにおける［ｋｅｙ］、［ｖａｌｕｅ］は、ｉｔｅｍｓの範囲内でしか使用せず、上記［ｋｅｙ］、［ｖａｌｕｅ］は、入力データの全範囲内に使用される。

【0047】

コンフィギュレーションデータは、同様に多種の形式で表すことができ、例えば、ＸＭＬ形式、ＪＳＯＮ形式等を使用する。計算論理及び相応の計算グラフを記述し易いために、本願の幾つかの実施例では、コンフィギュレーションデータは、ＹＡＭＬとＤＳＬと組み合わせで記述される。ＹＡＭＬ言語は、データを中心とした構成ファイル言語であり、実質的に汎用のデータシリアライズフォーマットを提供しており、人間がデータの読み書きを行うのに非常に便利である。ＹＡＭＬは、３つのデータ構造をサポートすることができ、オブジェクト、シーケンス及びスカラーを含み、オブジェクトはキー/値のペアのコレクションであり、シーケンスは１セットの順番に配列された値であり、スカラーは単一の再分割できない値である。ＹＡＭＬ言語の基本文法ルールは、大・小文字に敏感であり、インデントを使用して階層関係を表し、インデント時にＴａｂキーを使用することが許されず、スペースのみを使用することが許され、インデントしたスペースの数が重要ではなく、同じ階層の要素が左側に揃えていればよい。

【0048】

ドメイン固有言語（Ｄｏｍａｉｎ Ｓｐｅｃｉｆｉｅｄ Ｌａｎｇｕａｇｅ，ＤＳＬ）とは、ある業務分野に特化したコンピュータ言語を指し、ある特定の業務分野、例えば、金融、保険分野等にしか使用できない。ＤＳＬは、業務分野の専門家に簡単なプログラミングの方式で業務分野におけるすべての業務活動及び業務ルールを記述させることができることによって、ソフトウェアコードの可読性を高め、ソフトウェア開発者及び業務分野の専門家により良いコミュニケーションをさせることができる。

【0049】

本願実施例では、ＹＡＭＬとＤＳＬとを結びつける方式で、コンフィギュレーションデータを設置し、金融、保険分野のコンフィギュレーションデータの設置に簡単な文法特性を提供するので、勉強してマスターし易く、ユーザ１００の学習曲線を低減し、ユーザ１００がコンフィギュレーションデータを開発する効率を高めた。

【0050】

図６は本願の幾つかの実施例における保険料金を計算するためのコンフィギュレーションデータの例示を示している。図６に示すように、ａｐｐは、コンフィギュレーションデータに対応する名称、即ち「ｐｏｌｉｃｙ ｐｒｅｍｉｕｍ ｃａｌｃｕｌａｔｉｏｎ」を記述するために用いられ、コンフィギュレーションデータの名称は、通常、計算論理の演算プロセスの可視化をサポートするために用いられる。ｍａｉｎキーワードは、ａｐｐキーワードの直後について、計算論理の演算プロセスの開始を明示するために用いられる。計算論理の演算プロセスは、複数の計算ステップを含んでもよく、計算ステップは、ｓｔｅｐｓキーワードを用いて定義される。計算ステップには、図中の計算論理ｌｉｓｔのように、多種の計算論理が含まれてもよい。計算論理は、対応する名称があり、本願の幾つかの実施例では、計算論理の名称は、明示的に与えられてもよく、暗黙的に与えられてもよく、例えば、図中の計算論理ｌｉｓｔの名称は、「ｎａｍｅ:ｐｏｌｉｃｉｅｓ」で表示され、図では計算論理ｖａｒの名称は、直接与えられておらず、暗黙的に与えられている。類似に、計算論理の名称は、同様に計算論理の演算プロセスの可視化をサポートするために用いられてもよい。

【0051】

本願の幾つかの実施例では、計算論理は、サブ計算論理をさらに含んでもよく、サブ計算論理により該計算論理の出力データに対して後続処理を行う。図６に示すように、計算論理ｌｉｓｔには、サブ計算論理ｉｔｅｍが含まれ、ｉｔｅｍは、ｌｉｓｔの出力データに対して処理することができる。また、計算論理ｌｉｓｔには、複数のサブ計算論理ｉｔｅｍが含まれてもよく、各ｉｔｅｍが実行効率を高めるように並列に実行されてもよい。ここで、並行計算に関与するｉｔｅｍを指定するために、ｆｉｌｔｅｒｓキーワードによって条件のフィルタリングを行ってもよい、フィルタリング条件を満たすｉｔｅｍは、相応の計算を実行する。図６におけるフィルタの名称は、「ｃａｌｃ ｏｗｎ ｄａｍａｇｅ ｐａｒｔ」であり、フィルタリング条件は、ｉｔｅｍにおけるデータパラメータｃｏｄｅが予め定義された値ＯＤ_ＣＯＭＰに等しいか否かであり、ｃｏｄｅは、入力データに定義されたデータパラメータであり、フィルタリング条件を満たし、すなわちｃｏｄｅ値がＯＤ_ＣＯＭＰである場合、名称が「ｏｗｎ ｄａｍａｇｅ ｐａｒｔ」である動的計算グラフを実行する。

【0052】

動的計算グラフは、ｇｒａｐｈｓキーワードで定義され、動的計算グラフには、多種の保険料金の計算を完成するための計算論理が定義され、ｖａｒ、ｄｅｃｉｓｉｏｎｔｒｅｅ及びｅｘｐｒが含まれ、ｅｘｐｒには計算論理ｒｏｕｎｄが更に使用されている。図中の内容から分かるように、１つの保険料金の計算プロセスは、保険料率の計算と保険料金の計算を含み、保険料率の計算は、計算論理ｄｅｃｉｓｉｏｎｔｒｅｅで完成され、保険料金の計算は、計算論理ｅｘｐｒで完成される。計算論理ｄｅｃｉｓｉｏｎｔｒｅｅに対応する値ＳｕｍＩｎｓｕｒｅｄＲａｔｅは、外部データソースにおける定義データの参照名称である。外部データソースは、例えば、Ｅｘｃｅｌファイルであってもよく、Ｅｘｃｅｌファイルには、保険料率を計算するための多種の計算式及び相応のデータが定義されており、各計算式及び対応する結果データについては、外部からのアクセスに供するように対応する参照名称を提供する。

【0053】

本願の幾つかの実施例では、コンフィギュレーションデータには、計算論理の演算プロセスに関する演算構成が含まれてもよいし、具体的な計算論理に対応する特定の構成が含まれてもよい。特定の構成は、ある特定の計算論理のみに対応し、他の計算論理は特定の構成に対応しない。例えば、計算論理ｄｅｃｉｓｉｏｎｔｒｅｅにとって、通常の構成方式は、Ｅｘｃｅｌファイルで構成することを含み、Ｅｘｃｅｌファイルの内容は、決定木を構築するために必要な特定の構成を含む必要があり、計算論理ｅｘｐｒには決定木を構築するための特定の構成が存在しない。

【0054】

Ｓ４０２：サーバ側は、コンフィギュレーションデータを解析し、静的計算サブグラフを構築する。
サーバ側は、クライアント側から送信されたコンフィギュレーションデータを受信した後、コンフィギュレーションデータを解析し、解析結果に基づいて静的計算サブグラフを構築する。

【0055】

本願の幾つかの実施例では、サーバ側のコンフィギュレーションデータの解析は、コンフィギュレーションデータのうち階層構造を有する計算論理をシリアライズし、それからシリアライズ結果に基づいて静的計算サブグラフを構築する。ここのシリアライズとは、階層構造を有する計算論理をシーケンス構造を有する計算論理に変換する。例えば、階層構造を有する計算論理ｌｉｓｔは、複数のステップ（ｓｔｅｐ）を含んでもよく、そのうちの１つのステップ（ｓｔｅｐ）がｉｔｅｍ計算論理を含み、サーバ側は、コンフィギュレーションデータを解析した後、計算論理ｌｉｓｔとｉｔｅｍは、１つの順序付けられた配列（即ち実際の演算手順）にシリアライズされることができる。シリアライズ後に得られた配列は、フローベースプログラミング技術（Ｆｌｏｗ-ｂａｓｅｄ Ｐｒｏｇｒａｍｍｉｎｇ，ＦＢＰ）により静的計算サブグラフを構築する。フローベースプログラミングは、データフロープログラミングパラダイムであり、コンポーネントによるソフトウェア工学方法の１つである。フローベースプログラミングは、ソフトウェアアプリケーションを１セットのプロセス（Ｐｒｏｃｅｓｓ）とみなし、プロセス間は接続を介して通信し、プロセスは、ポート（Ｐｏｒｔ）を介してアクセスして接続し、このような方式は、コンピュータネットワークを介して通信することに類似する。フローベースプログラミングは、異なるコンポーネントを用いてデータを変換し、コンポーネントは本質的にパッケージのモジュール又は関数であり、データフローは、プロセス間の通信システムによってコンポーネント間で伝達される。フローベースプログラミングにおいて、ソフトウェアアプリケーションは有向グラフとして表され、その中のプロセスが有向グラフのノードとされ、プロセス間の接続が有向グラフの辺とされる。

【0056】

ここで、静的計算サブグラフは、計算論理をノードとし、計算論理の間のデータの流れ方向は辺の有向グラフである。静的計算サブグラフは、最終的な計算リンクではなく、一部の情報が欠落している。例えば、計算論理ｉｔｅｍに対して並列計算するには、ｉｔｅｍに対応する入力データを知る必要があるが、コンフィギュレーションデータには入力データが含まれない。また、フィルタｆｉｌｔｅｒにより計算グラフｇｒａｐｈを実行するには、ｇｒａｐｈに対応する入力データにはデータパラメータｃｏｄｅが含まれているか否かを知る必要があり、かつ、ｃｏｄｅのデータ値が予め設定された値ＯＤ_ＣＯＭＰに等しいか否かを知る必要がある。

【0057】

Ｓ４０３：サーバ側は、入力データと静的計算サブグラフとを接続し、計算リンクを決定する。
サーバ側で静的計算サブグラフを得た後、入力データを静的計算サブグラフに接続することによって、完全な情報を含む動的計算サブグラフ、即ち計算リンクを得る。ここで、入力データを静的計算サブグラフに接続するとは、静的計算サブグラフにおいて具体的なデータを必要とする箇所と、入力データのうちの正確なデータとを対応付けることである。例えば、静的計算サブグラフにおいてあるデータパラメータは、具体的なデータ値を必要とするため、入力データのうち該データパラメータ名称で指定されるデータを静的計算サブグラフにおける該データパラメータの位置に対応させる。
正確なデータの入力は、静的計算サブグラフにおける計算論理により完成される。例えば、計算論理ｉｔｅｍは、計算論理ｉｔｅｍｓの数に応じて相応数のコルーチン（ｇｏｒｏｕｔｉｎｅ）を新規作成し、ｉｔｅｍに対応する静的計算サブグラフの接続を完成する。また、計算論理ｆｉｌｔｅｒは、入力データにおけるデータパラメータのデータ値がフィルタリング条件を満たすか否かを判断することにより、データ値を静的計算サブグラフの次のノードに伝達するか、それとも、対応する静的計算サブグラフに接続されるかを決定する。

【0058】

サーバ側で得られた動的計算サブグラフにおけるノードは、１つの入力ポートと１つの出力ポートとを含み、ノードは、入力ポートを介して１つ前のノードの出力データを受信し、出力ポートを介して自ノードにおける計算論理の演算完了後の計算結果を次のノードに出力することによって、ノードの間にデータの流れを実現する。

【0059】

Ｓ４０４：サーバ側は、計算リンクを実行し、計算結果を決定する。
サーバ側は、動的計算サブグラフである計算リンクを取得した後、動的計算サブグラフが完全な情報を既に備えているため、該グラフにおいて計算論理に対応する入力データがあり、これによって、サーバ側は、動的計算サブグラフにおけるノード方向に従ってノードにおける計算論理を順次実行し、動的計算サブグラフの全てのノードでは実行完了した後、最終的な計算結果を得ることができる。

【0060】

Ｓ４０５：サーバ側は、計算結果をクライアント側に返す。
ここで、サーバ側は、計算結果をクライアント側に返し、計算結果をそのままクライアント側に返信してもよいし、計算結果に対して一定の処理を行ってからクライアント側に返してもよい。本願の幾つかの実施例では、サーバ側は、計算結果をフォーマット処理した後に、クライアント側に返してもよい。具体的に言えば、コンフィギュレーションデータには、計算結果のフォーマット配置情報が含まれてもよく、サーバ側は、コンフィギュレーションデータにおけるフォーマット配置情報に基づいて計算結果をフォーマット処理してもよい。フォーマット処理は、例えば、計算結果のうちの中間データの除去や、計算結果におけるデータパラメータの名称の変換などを含んでもよい。
本願の実施例では、クライアント側は、入力データ及びコンフィギュレーションデータをサーバ側に提供し、入力データのデータ組織構造、データパラメータ名称等のコンフィギュレーションデータにおける計算論理に対応する特定の配置が相応の制約に合致する場合、サーバ側でランニングする計算論理処理プロセスは、ステートレスアプリケーションに類似することによって、サーバレスアーキテクチャモード（ｓｅｒｖｅｒｌｅｓｓ）での配置に非常に適している。

【0061】

本願に開示されたメカニズムの各実施例は、ハードウエア、ソフトウェア、ファームウエア又はこれらの実現方法の組み合わせに実現されてもよい。本願の実施例は、プログラマブルシステムで実行されるコンピュータプログラム又はプログラムコードとして実現してもよい、該プログラマブルシステムは、少なくとも１つのプロセッサ、メモリシステム（揮発性及び不揮発性メモリ及び／又は記憶素子を含む）、少なくとも１つの入力デバイス及び少なくとも１つの出力デバイスを含む。

【0062】

本願に記載の各機能を実行して出力情報を生成するように、プログラムコードを入力命令に用いてもよい。既知の方式で出力情報を１つ又は複数の出力デバイスに用いてもよい。本願の目的のために、処理システムは、例えば、デジタル信号プロセッサ（Ｄｉｇｉｔａｌ Ｓｉｇｎａｌ Ｐｒｏｃｅｓｓｏｒ，ＤＳＰ)、マイクロコントローラ、特定用途向け集積回路（Ａｐｐｌｉｃａｔｉｏｎ Ｓｐｅｃｉｆｉｃ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ，ＡＳＩＣ)又はマイクロプロセッサのようなプロセッサを有する如何なるシステムを含む。

【0063】

プログラムコードは、処理システムと通信するように、高級プログラム言語又はオブジェクト指向のプログラミング言語で実現されてもよい。必要に応じて、アセンブリ言語や機械語でプログラムコードを実現してもよい。事実上、本願に記載のメカニズムは、如何なる特定のプログラミング言語の範囲に限定されるものではない。いずれの場合においても、該言語は、コンパイラ言語又はインタプリタ言語であってもよい。

【0064】

幾つかの場合には、開示された実施例は、ハードウエア、ファームウエア、ソフトウェア又はそれらの如何なる組み合わせで実現されてもよい。開示された実施例は、１つまたは複数の一時的または非一時的な機械読み取り可能(例えば、コンピュータ可読)の記憶媒体に担持または記憶される命令として実現されてもよく、１つ又は複数のプロセッサによって読み出されて実行されてもよい。例えば、命令は、ネットワークを介して又は他のコンピュータ可読媒体によって配信されてもよい。そのため、機械可読媒体は、機械（例えば、コンピュータ）が読み取り可能な形式で情報を記憶又は伝送するための如何なるメカニズムを含んでもよく、フロッピーディスク、コンパクトディスク、光ディスク、読み出し専用メモリ（ＣＤ-ＲＯＭｓ）、光磁気ディスク、読み出し専用メモリ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ，ＲＯＭ）、ランダムアクセスメモリ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ，ＲＡＭ）、消去可能プログラマブル読み出し専用メモリ（Ｅｒａｓａｂｌｅ Ｐｒｏｇｒａｍｍａｂｌｅ Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ，ＥＰＲＯＭ）、電気的消去可能プログラマブル読み出し専用メモリ（Ｅｌｅｃｔｒｉｃａｌｌｙ Ｅｒａｓａｂｌｅ Ｐｒｏｇｒａｍｍａｂｌｅ Ｒｅａｄ-Ｒｅａｄ Ｍｅｍｏｒｙ，ＥＥＰＲＯＭ）、磁気カード又は光カード、フラッシュメモリ、又はインターネットを利用して電気的、光、音響又は他の形式の伝播信号で情報（例えば、搬送波、赤外信号・デジタル信号等）を伝送するための有形の機械可読メモリを含んでもよいが、これらに限定されるものではない。したがって、機械可読媒体は、機械（例えば、コンピュータ）可読の形式では電子命令又は情報を記憶・伝送するのに適した如何なるタイプの機械可読媒体を含む。

【0065】

図面において、特定の配置及び／又は順序で幾つかの構造又は方法の特徴を示してもよい。しかしながら、このような特定の配置及び／又は順序付けを必要としない可能性があることが理解されるべきである。幾つかの実施例では、これらの特徴は、例示的な図に示された態様及び／又は順序とは異なる態様及び／又は順序で配置されてもよい。また、特定の図において構造又は方法の特徴が含まれていることは、全ての実施例においてこのような特徴が必要とされことを暗示することを意味しておらず、しかも、幾つかの実施例では、これらの特徴を含まなくてもよく、又は他の特徴と組み合わせてもよい。

【0066】

なお、本願の各デバイスの実施例に言及した各ユニット／モジュールのいずれも、論理ユニット／モジュールであり、物理的には、１つの論理ユニット／モジュールは、１つの物理的ユニット／モジュールであってもよいし、１つの物理的ユニット／モジュールの一部であってもよく、複数の物理的ユニット／モジュールの組み合わせで実現されてもよい。これらの論理ユニット／モジュール自体の物理的な実現形態は最も重要ではなく、これらの論理ユニット／モジュールが実現する機能の組み合わせこそは、本願で提出された技術的課題を解決する鍵である。又、本願のイノベーション部分を強調するために、本願の上記各デバイスの実施例は、本願で提出された技術的課題の解決と密接な関係があまりないユニット／モジュールを導入しておらず、これは上記デバイスの実施例には他のユニット／モジュールが存在しないことを意味するものではない。

【0067】

なお、本特許の例示及び明細書において、第一や第二などのような関係用語は、１つの実体又は操作ともう１つの実体又は操作とを区別するためのものに過ぎず、必ずしもこれらの実体又は操作の間に如何なるこのような実際の関係又は順序が存在することを要求又は示唆するものではない。又、用語「包含」、「含む」又はその如何なる他の変形体は、非排他的包含をカバーすることを意図し、これによって、一連の要素を含むプロセス、方法、物品又はデバイスは、それらの要素を含むだけでなく、明確に列挙されていない他の要素も含み、又はこのようなプロセス、方法、物品又はデバイスに固有の要素をさらに含む。より多くの制限がない場合には、語句「１つの…を含む」で限定された要素は、前記要素を含むプロセス、方法、物品又はデバイスには別の同じ要素がさらに存在することを排除するものではない。

【0068】

本願の幾つかの好ましい実施例を参照することで、本願について図示と記述を行ったが、当業者は、本願の主旨及び範囲から逸脱することなく、形式と細部について様々な変更が可能であることを理解すべきである。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【手続補正書】

【提出日】2024-04-17

【手続補正1】

【補正対象書類名】特許請求の範囲

【補正対象項目名】全文

【補正方法】変更

【補正の内容】

【特許請求の範囲】

【請求項1】

サーバ側及びクライアント側を含む計算論理の処理システムにおいて、
前記クライアント側は、計算論理を実行するために必要なデータ値を記述するための入力データと、業務処理中の前記計算論理の配置情報及び前記計算論理の間の関連情報を記述するためのコンフィギュレーションデータを取得してサーバ側に送信するためのものであり、
前記サーバ側は、前記コンフィギュレーションデータを解析し、静的計算サブグラフを生成するためのものであり、前記の静的計算サブグラフを生成することは、フローベースプログラミング技術により前記静的計算サブグラフを生成し、前記静的計算サブグラフが有向グラフとして表され、前記計算論理は前記有向グラフのノードであり、前記計算論理の間のデータ流れ方向は前記有向グラフの辺であり、
前記サーバ側は、入力データと静的計算サブグラフとを接続し、動的計算サブグラフを生成するためのものであり、前記の入力データと静的計算サブグラフとを接続することは、前記静的計算サブグラフにおけるデータ値を必要とするデータパラメータと、前記入力データのうちの前記データパラメータに対応するデータ値とを対応付けることを含み、
前記サーバ側は、前記動的計算サブグラフを実行し、計算結果を得るためのものであることを特徴とする計算論理の処理システム。

【請求項2】

前記サーバ側は、階層構造を有する計算論理をシリアライズするためのものであり、前記の階層構造を有する計算論理は、複数のステップを含み、前記ステップはサブ計算論理を含み、
前記サーバ側は、シリアライズ結果に基づいて静的計算サブグラフを生成するためのものであることを特徴とする請求項１に記載のシステム。

【請求項3】

前記サーバ側は、フローベースプログラミング技術により、シリアライズ結果に基づいて静的計算サブグラフを生成するためのものであることを特徴とする請求項２に記載のシステム。

【請求項4】

前記サーバ側は、前記静的計算サブグラフにおける計算論理のデータパラメータに基づき、前記入力データにおいて対応のデータ値を決定して前記データ値を前記データパラメータに接続するためのものであることを特徴とする請求項１に記載のシステム。

【請求項5】

前記の前記データ値を前記データパラメータに接続することは、前記データ値を前記静的計算サブグラフにおける前記データパラメータに代入することを含むことを特徴とする請求項４に記載のシステム。

【請求項6】

前記サーバ側は、前記動的計算サブグラフを実行し、初歩的な計算結果を得、前記コンフィギュレーションデータのうちのフォーマット配置情報に基づいて前記初歩的な計算結果をフォーマット処理し、フォーマット後のデータを得て、前記計算結果とするためのものであることを特徴とする請求項１に記載のシステム。

【請求項7】

前記サーバ側は、前記動的計算サブグラフにおける計算論理に対応する入力データに基づいて、前記計算論理を実行し、前記初歩的な計算結果を得るためのものであることを特徴とする請求項６に記載のシステム。

【請求項8】

前記計算論理は、少なくとも計算式、拡張関数、変数、フィルタ、決定木のうちの１つを含むことを特徴とする請求項１に記載のシステム。

【請求項9】

前記入力データのフォーマットは、ＪＳＯＮ形式であり、前記コンフィギュレーションデータは、ＹＡＭＬとＤＳＬとの組み合わせにより記述されることを特徴とする請求項１に記載のシステム。

【国際調査報告】