TW201512992A - 資訊處理裝置、資訊處理方法、程式、記憶媒體 - Google Patents

資訊處理裝置、資訊處理方法、程式、記憶媒體 Download PDF

Info

Publication number
TW201512992A
TW201512992A TW103128807A TW103128807A TW201512992A TW 201512992 A TW201512992 A TW 201512992A TW 103128807 A TW103128807 A TW 103128807A TW 103128807 A TW103128807 A TW 103128807A TW 201512992 A TW201512992 A TW 201512992A
Authority
TW
Taiwan
Prior art keywords
information
api
application
service
license
Prior art date
Application number
TW103128807A
Other languages
English (en)
Other versions
TWI518597B (zh
Inventor
Tatsuya Yoshinari
Original Assignee
Rakuten Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Rakuten Inc filed Critical Rakuten Inc
Publication of TW201512992A publication Critical patent/TW201512992A/zh
Application granted granted Critical
Publication of TWI518597B publication Critical patent/TWI518597B/zh

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/629—Protecting access to data via a platform, e.g. using keys or access control rules to features or functions of an application
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/10—Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems

Abstract

有關隨API使用之服務，可以適切管理應用提供者及應用利用者的實際工時。資訊處理裝置，係對從應用提供者裝置已發送完畢之有關用了使用API的應用程式之服務的API利用要求，發行服務代碼，使服務識別資訊及API使用資訊與服務代碼對應並予以登錄。而且，因應應用提供者所致之利用者特定資訊並對每位應用利用者發行未承認狀態的許可資訊。該許可資訊係應用利用者進行承認，登錄許可承認資訊。服務實行時，係使用這樣的登錄資訊，進行認證，許可API使用。於該場合，利用經由服務代碼應用提供者可以識別，經由許可資訊應用利用者可以識別的方式，生成各個API使用的實際工時資訊。

Description

資訊處理裝置、資訊處理方法、程式、記憶媒體
本發明，係有關在使用API(應用程式介面)的服務中所用的資訊處理裝置及其之資訊處理方法、實現資訊處理裝置的程式、及記憶程式之記憶媒體。
〔先前技術文獻〕 〔專利文獻〕
〔專利文獻1〕日本特開2006-178658號專利公報
〔專利文獻2〕日本特開2010-146169號專利公報
上述專利文獻1中記載有：對已被作成的服務程式中的登錄要求進行查核處理，確認被規定在服務程式之全部的功能模組是否為可以利用的功能模組，OK的話對應到服務ID(identification，識別)發行、及客戶ID來登錄。
在上述專利文獻2記載有：應用伺服器對來自客戶的請求進行認證，為API存取要求的場合，使認證處理結果附帶至請求發送到API伺服器，API伺服器係根據認證處 理結果進行請求處理。
例如在網際網路服務的方面，進行有程式利用API在系統間進行資訊的傳輸。
有關API的使用，係存在有提供有把使用了API的網路服務予以實現之應用程式(以下稱為「服務應用」)之應用提供者、享受服務應用所帶來的服務之應用利用者、提供API之伺服器管理者、以API處理資料之提供者貨所有者等之各種的立場。
在這樣的狀況下，從提供API之伺服器管理者側來見，就有關與API使用相關連之服務應用的提供者、利用者，是有所謂確實地掌握API使用實際工時之請求。
在此，本發明係無損於使用API的服務之有用性，在可以確保API使用或API所處理的資料的安全性之下，可以確實地進行有關API使用之應用提供者、應用利用者的API使用實際工時管理。
第1，有關本發明之資訊處理裝置，係具備構成為如下之系統：使用預先被準備好的API之應用程式，是藉由複數位、1位或是複數位應用提供者而提供，複數位應用利用者之每一位可以享受可以被自己利用之應用程 式的實行所致之服務；其特徵為具備：登錄資訊取得部，係取得關連了以下之登錄資訊：從有關用了使用API之應用程式的服務之應用提供者裝置所已被指定之服務識別資訊及使用API之API使用資訊、與表示有該服務作為API使用服務而已被登錄之服務代碼、與對應到特定從前述應用提供者裝置所被指定之應用利用者之利用者特定資訊所已生成之許可資訊、與表示使用了來自藉由對應到前述許可資訊之利用者特定資訊所示之應用利用者的應用利用者裝置之在前述API使用資訊所示之API之資訊存取權限之承認或是不承認之許可承認資訊；認證處理部，係在有了隨前述應用程式的實行之API使用要求之際，根據有關該API使用要求之服務代碼與許可資訊，參閱經由前述登錄資訊取得部所取得的登錄資訊，進行至少包含以下之認證處理：服務代碼所致之正規登錄的確認、以該API使用要求被要求使用之API與API使用資訊的一致確認、許可資訊的正當性的確認、及許可承認資訊所致之承認確認，因應認證結果許可已被要求之API使用；以及實際工時管理部，係在許可了API使用之場合，根據API使用要求之服務代碼，生成應用提供者的實際工時資訊，而且根據許可資訊，生成應用利用者的實際工時資訊。
這樣的資訊處理裝置，首先在提供有複數個應用程式的狀況下，複數位服務利用者之每一位，用有可以享受可以被自己利用之應用程式的實行所帶來的服務之系統。接著，在該資訊處理裝置，在利用應用程式實行隨API使用 的服務之場合，進行使用了服務代碼與許可資訊之認證。
應用提供者，係提供與服務代碼一體化之應用程式。 服務代碼係附帶API使用資訊與服務識別資訊。應用利用者係使用本身所承認之許可資訊，實行應用程式。在這樣的前提下，以進行用了服務代碼與許可資訊之認證的方式，限制應用利用者沒有意圖之服務利用、或API使用所致之資訊存取。
更進一步，進行用了服務代碼與許可之服務的實行時的實際工時管理。經由服務代碼可以做應用提供者的實際工時管理，經由許可資訊可以做應用利用者的實際工時管理。
第2，有關上述本發明之資訊處理裝置中，期望：前述實際工時管理部，係根據API使用要求之服務代碼，生成對應用提供者之會計資訊。
亦即，可以進行對應用提供者之個別會計。
第3，有關上述本發明之資訊處理裝置中，期望：前述實際工時管理部，係根據API使用要求之許可資訊，生成對應用利用者之會計資訊。
亦即，可以進行對應用利用者之個別會計。
第4，有關上述本發明之資訊處理裝置中，期望：前述認證處理部，係接收從已實行前述應用程式之外部終端裝置連同API使用要求一起發送之前述服務代碼及前述許可資訊，進行認證處理。
亦即，使用同時發送API使用要求並附帶服務代碼或 許可資訊之登錄資訊，進行認證。
第5，有關上述本發明之資訊處理裝置中，期 望：前述認證處理部，係在就全部之服務代碼、服務識別資訊、API使用資訊、許可資訊、及許可承認資訊，可以確認的場合，許可有關API使用要求之API使用。
經此，實現最優先確保資訊的安全性之運用。
第6，有關上述本發明之資訊處理裝置中，期望：於前述登錄資訊包含對應到前述許可資訊之終端識別資訊，前述認證處理部，係在認證處理中，就發送實行了前述應用程式之API使用要求完畢之外部終端裝置，也進行用了前述終端識別資訊之認證。
亦即，以終端單位認證正規使用。
第7，有關本發明之資訊處理方法，乃是具備上述的系統之資訊處理裝置之資訊處理方法；其特徵為：取得有關用了使用API的應用程式之服務所致之API使用要求之服務代碼與許可資訊；對登錄資訊，其關連了從有關前述服務的應用提供者裝置所已被指定之服務識別資訊及API使用資訊、與表示有該服務作為API使用服務而已被登錄之服務代碼、與對應到特定從前述應用提供者裝置所被指定之應用利用者之利用者特定資訊所已生成之許可資訊、與表示使用了來自藉由對應到前述許可資訊之利用者特定資訊所示之應用利用者的應用利用者裝置之在前述API使用資訊所示之API之資訊存取權限之承認或是不承認之許可承認資訊，根據有關前述API使用要求之服務代 碼與許可資訊進行存取；參閱在前述存取所取得的登錄資訊，進行至少包含以下之認證處理：服務代碼所致之正規登錄的確認、以該API使用要求被要求使用之API與API使用資訊的一致確認、許可資訊的正當性的確認、及許可承認資訊所致之承認確認，因應認證結果許可已被要求之API使用；在許可了API使用之場合，根據API使用要求之服務代碼，生成應用提供者的實際工時資訊，而且根據許可資訊，生成應用利用者的實際工時資訊。
第8，有關本發明之程式，乃是資訊處理裝置實行作為上述資訊處理方法而實行之處理之程式。
第9，有關本發明之記憶媒體，乃是記憶了上述程式之程式。
經由這些的程式或記憶媒體實現上述的資訊處理裝置。
根據本發明，經由服務代碼可以管理應用提供者，而且經由許可資訊可以管理應用利用者。而且，於認證OK的場合進行實際工時管理。經此，對API使用之實際工時，成為可以就各個應用提供者、應用利用者進行適當的API使用的實際工時管理。
1‧‧‧EC系統
2‧‧‧網路
3、3A、3B‧‧‧應用提供者裝置
4‧‧‧應用利用者裝置
10‧‧‧登錄伺服器
11‧‧‧登錄管理部
11a‧‧‧服務代碼處理部
11b‧‧‧許可處理部
12‧‧‧提供者WEB
13‧‧‧利用者WEB
20‧‧‧API伺服器
21‧‧‧認證部
21a‧‧‧認證處理部
21b‧‧‧登錄資訊取得部
22‧‧‧實際工時管理部
30‧‧‧登錄資料庫
31‧‧‧商店資訊資料庫
32‧‧‧實際工時資料庫
〔圖1〕為本發明的實施方式之網路系統之說明圖。
〔圖2〕為實施方式的電腦裝置之方塊圖。
〔圖3〕為實施方式的EC系統之方塊圖。
〔圖4〕為實施方式的登錄資訊之說明圖。
〔圖5〕為實施方式的登錄時的動作之說明圖。
〔圖6〕為實施方式的服務代碼處理之說明圖。
〔圖7〕為實施方式的許可處理之說明圖。
〔圖8〕為實施方式的許可承認處理之說明圖。
〔圖9〕為實施方式的提供者WEB的API使用登錄要求的輸入畫面之說明圖。
〔圖10〕為實施方式的提供者WEB的服務代碼發行畫面之說明圖。
〔圖11〕為實施方式的提供者WEB的許可發行畫面之說明圖。
〔圖12〕為實施方式的利用者WEB的許可清單畫面之說明圖。
〔圖13〕為實施方式的利用者WEB的許可內容確認畫面之說明圖。
〔圖14〕為實施方式的利用者WEB的許可承認畫面之說明圖。
〔圖15〕為實施方式的服務利用時的動作之說明圖。
〔圖16〕為實施方式的服務利用時的處理例I之說明圖。
〔圖17〕為實施方式的服務利用時的認證處理之流程圖。
〔圖18〕為實施方式的服務利用時的實際工時管理處理之流程圖。
〔圖19〕為實施方式的實際工時資訊之說明圖。
〔圖20〕為實施方式的其他的登錄資訊之說明圖。
〔圖21〕為實施方式的服務利用時的動作之說明圖。
〔圖22〕實施方式的服務利用時的處理例II之說明圖。
〔圖23〕為實施方式的服務利用時的認證處理之流程圖。
〔圖24〕實施方式的服務利用時的處理例III之說明圖。
〔圖25〕為實施方式的服務利用時的動作之說明圖。
〔圖26〕實施方式的服務利用時的處理例IV之說明圖。
以下，以下列順序說明實施方式。
<1．網路系統構成>
<2．EC管理系統>
<3．登錄時的處理>
<4．服務實行時之處理例I>
<5．服務實行時之處理例II>
<6．服務實行時之處理例III>
<7．服務實行時之處理例IV>
<8．EC管理系統的實施之效果>
<9．程式及記憶媒體>
<10．變形例>
<1．網路系統構成>
於圖1表示網路系統之例。該網路系統係作為EC(EC：electronic commerce(電子商務))系統而發揮功能。
圖1之EC管理系統1相當於本發明的資訊處理裝置之實施方式。
網路系統，係透過網路2，構成EC管理系統1、應用提供者裝置3A、3B、3C...、應用利用者裝置4A、4B、4C...可以相互通訊。尚且沒有特別區別應用提供者裝置3A、3B...的場合，總稱為「應用提供者裝置3」。同樣沒有特別區別應用利用者裝置4A、4B、4C...的場合，總稱為「應用利用者裝置4」。
更進一步「應用提供者裝置」「應用利用者裝置」，係簡單略稱為「提供者裝置」「利用者裝置」。
在此網路系統，於EC管理系統1中提供可以使用之各種API。複數位應用提供者之每一位提供有使用 此預先準備好的API之服務應用，複數位應用利用者之每一位可以享受到可以被自己利用之應用程式的實行所帶來的網路服務(說明上、簡單稱為「服務」)。
尚且所謂「服務」，指的是藉由作為1個標題之服務應用所被實現之服務。
提供者裝置3，乃是作為應用提供者所使用的網路終端之資訊處理裝置。
所謂應用提供者，指的是提供實現服務的程式之服務應用的個人或團體。例如進行服務應用的開發或販賣之軟體開發者/廠商，或者是以雲端服務等提供服務應用之服務的業者等。
在圖中提供者裝置3A，係作為服務應用之套件提供者所用的資訊處理裝置。所謂此套件提供者，乃是進行例如作為複數個服務應用SA1、SA2、SA3之各程式的下載服務、或者是在光碟之其他的套件媒體下的服務應用的販賣．讓渡等之團體或個人。
提供者裝置3B，係作為實行因應應用利用者的委託等而所有之服務應用SA10，把雲端服務性的服務提供給應用利用者之團體或個人所使用之資訊處理裝置。例如在通過網際網路提供服務給顧客(應用利用者)之目的下實行服務應用之所謂的ASP(Application Service Provider，應用服務提供者)，為相當於此場合的應用提供者。
而且提供者裝置3C，乃是提供作為複數個服務應用SA20、SA21的各程式之應用提供者所使用的資訊處理裝 置。
如此本實施方式之網路系統，係以複數位應用提供者之每一位提供1個或複數個服務應用的方式，得到提供複數個服務應用之狀況。而且其服務應用，乃是使用EC管理系統1所預先準備的API之程式。
尚且、在圖1表示存在有複數位應用提供者的場合，但也可能有單一位應用提供者提供複數個服務應用之形態。
利用者裝置4，乃是作為應用利用者所使用的網路終端之資訊處理裝置。
所謂應用利用者，乃是對應用提供者來說相當於顧客之存在，例如經由商店進行利用網路之商品販賣者(商品販賣業者)。例如所謂商店，乃是網站之電子商店或是實際的商店。圖中，利用者裝置4A、4B、4C，係表示作為不同的販賣業者的資訊處理裝置。
應用利用者，係經由提供者裝置3所提供的服務應用，接受例如庫存管理服務、販賣管理服務等的服務，可以圖求販賣業務的效率化等。
尚且應用利用者並不限於販賣業者，是預設為享受某服務應用所帶來的服務之全部的團體、個人。所謂販賣業者，舉有一例。
藉由1位或複數位應用提供者，以提供複數個服務應用的方式，各應用利用者，係在複數個服務應用之中，利用自己考慮到為有必要的服務應用，可以享受其服務應用 所帶來的服務。
EC管理系統1，係在本實施方式中，作為把實現電子商務系統之該網路系統中如下的功能予以實行之資訊處理裝置。
．服務應用所使用的API之提供
．有關使用API的服務應用的登錄之處理
．有關服務應用的實行之際的認證之處理
．有關伴隨服務應用的實行之API使用實際工時的管理之處理
關於這些的詳細部分後述之，但EC管理系統1，係具備為了能夠實行這些的處理之必要的構成。
而且EC管理系統1，係亦可具有作為電子商務系統的管理者的角色。例如，亦可具有進行作為應用利用者之電子商店的開設、或電子市場提供等的服務之功能。
網路2的構成係預設有多樣的例子。例如、預設有：網際網路、內部網路、外部網路、LAN(Local Area Network，區域網路)、CATV(Community Antenna TeleVision，公用天線電視)通訊網、虛擬私有網路(Virtual Private Network)、電話網路、行動通訊網路、衛星通訊網路等。
而且，有關構成網路2的全部或一部分之傳輸媒介也預設有多樣的例子。例如，可以利用IEEE(Institute of Electrical and Electronics Engineers，美國電機暨電子工程師學會)1394、USB(Universal Serial Bus，通用序列 匯流排)、電力線傳輸、電話線等之有線方式，亦可利用IrDA(Infrared Data Association，紅外通訊技術)類之紅外線、藍牙(登錄商標)、802.11無線、攜帶式電話網路、衛星鏈路、地面電波數位網路等之無線方式。
尚且，在以上的圖1中，僅揭示有直接關連 到後述之本實施方式的動作之資訊處理裝置(網路終端)，實際上也有各種的資訊處理裝置關連到本例之網路系統。
例如存在有：從作為應用利用者的商店進行透過網路2的商品購入之一般使用者的資訊處理裝置、以EC管理系統1所提供之API的開發者的資訊處理裝置、進行API的承認/管理/維修等之API管理者的資訊處理裝置等。
繼續，打構成於圖1所示之EC管理系統1、 提供者裝置3、利用者裝置4之資訊處理裝置的硬體構成表示於圖2。EC管理系統1、提供者裝置3、利用者裝置4等之各裝置，係作為可以進行資訊處理及資訊通訊之於圖2所示般的電腦裝置而可以實現。
圖2中，電腦裝置的CPU(Central Processing Unit，中央處理單元)101，係根據被記憶在ROM(Read Only Memory)102的程式、或是從記憶部108載到RAM(Random Access Memory)103的程式，實行各種的處理。於RAM103，而且在CPU101實行各種的處理之下，也適宜記憶必要的資料等。
CPU101、ROM102、及RAM103，係透過匯流排104 相互連接。於此匯流排104，也被連接到輸出入介面105。
於輸出入介面105，連接有：利用鍵盤、滑鼠、觸控面板等所構成的輸入部106、LCD(Liquid Crystal Display，液晶顯示器)、CRT(Cathode Ray Tube，陰極射線管)、有機EL(Electroluminescence，電致發光)面板等所構成的顯示器、以及利用揚聲器等所構成的輸出部107、利用HDD(Hard Disk Drive，硬式磁碟機)或快閃記憶體裝置等所構成的記憶部108、進行透過網路2的通訊處理或機器間通訊的通訊部109。
於輸出入介面105，而且因應於必要，連接媒體裝置110，適當安裝有磁性碟片、光碟、光磁性碟片、或者是半導體記憶體等的可移除式媒體111，進行對可移除式媒體111之資訊的寫入或讀出。
在這樣的電腦裝置中，經由通訊部109的通訊，可以進行資料或程式的上傳、下載，或是透過可移除式媒體111之資料或程式的傳輸。
以CPU101根據各種的程式進行處理動作的方式，於各個EC管理系統1、提供者裝置3、利用者裝置4中實行後述之資訊處理或通訊。
尚且、構成EC管理系統1、提供者裝置3、利用者裝置4之資訊處理裝置，係不限於以單一個來構成如圖2般的電腦裝置，亦可把複數個電腦裝置予以系統化來構成。複數個電腦裝置，係可以利用LAN等來系統化，亦 可經由利用網際網路等之VPN等來遠距離地配置。
<2．EC管理系統>
把例如作為上述的電腦裝置而實現EC管理系統1的功能構成，用圖3進行說明。圖3係把在本實施方式中有關EC管理系統1所進行的動作之必要的功能，亦即主要藉由CPU101的處理及制御所實現的功能予以區塊化而進行表示。
本實施方式的EC管理系統1係作為其功能構成，具備：登錄伺服器10、API伺服器20、登錄資料庫30、商店資訊資料庫31、實際工時資料庫32。
登錄伺服器10，係進行有關藉由使用API的 服務應用所實現的服務之登錄處理。為此，設有持有作為服務代碼處理部11a及許可處理部11b的功能之登錄管理部11。
尚且，揭示有：服務代碼處理部11a作為進行有關服務代碼的處理之功能、許可處理部11b係作為進行有關許可資訊的處理之功能，為登錄管理部11所具有之構成。實際上服務代碼處理部11a與許可處理部11b，係藉由個個的程式所實現，或者是藉由作為已關連之複數個程式所實行之功能所實現。更進一步可以掌握分別揭示了1個程式中所實行的服務代碼關連處理與許可資訊關連處理。
登錄管理部11，係利用作為服務代碼處理部11a的功能，進行對於從提供者裝置3所發送完畢之有關 用了使用API的服務應用之服務的API使用登錄要求，生成服務代碼的處理。而且，有關該服務，進行使服務識別資訊、及API使用資訊，與服務代碼對應後登錄到登錄資料庫30之處理。
尚且所謂服務識別資訊，乃是特定使用API之服務應用(亦即用了該服務應用之服務)之資訊。例如服務應用之製品識別代碼或製品名稱等。
而且API使用資訊，乃是特定服務應用所使用的API之資訊。例如為後述之API伺服器20所管理之API24的識別代碼或API名稱等。
而且登錄管理部11，係利用作為許可處理部 11b的功能，進行對應到從提供者裝置3所發送完畢之有關服務的利用者特定資訊生成未承認狀態的許可資訊之處理。而且進行使許可資訊，與服務代碼對應後登錄到登錄資料庫30之處理。
尚且所謂利用者特定資訊，乃是把享受服務應用之服務的應用利用者予以特定之資訊。例如考慮有：應用利用者的ID、管理代碼、利用者裝置4的識別資訊、或者是應用利用者開設在EC管理系統1的管理之下的商店(作為商店的網站)之URL(Uniform Resource Locator)等。
更進一步登錄管理部11，係利用作為許可處 理部11b的功能，對藉由對應到許可資訊之利用者特定資訊所揭示的應用利用者進行許可發行通知。接著受理來自利用者裝置4的指示之許可承認資訊，進行使該些對應到 許可資訊登錄到登錄資料庫30之處理。
登錄管理部11，係為了進行登錄處理，可以對登錄資料庫30進行存取。
而且登錄管理部11，係構成利用網路通訊對提供者裝置3或利用者裝置4可以通訊。
更進一步登錄管理部11，係為了來自提供者裝置3之用以登錄的資訊輸入或資訊提示，提供有提供者網站12(以下書寫成「提供者WEB」)，透過提供者WEB12進行作為服務代碼處理部11a及許可處理部11b的功能之所謂提供者裝置3的資訊傳輸。
而且登錄管理部11，係為了來自利用者裝置4之用以登錄的資訊輸入或資訊提示，提供有利用者網站13(以下書寫成「利用者WEB」)，透過利用者WEB12進行作為許可處理部11b的功能之所謂利用者裝置4的資訊傳輸。
在此，“服務代碼”與“許可資訊”，係在各自實 際使用上，預設有以識別代碼(identification code)、通行碼(password)、秘密代碼(secret code)、鍵資料(key data)、鍵資訊(key information)、登錄代碼(registration code)、認證代碼(authentication code)、ID代碼(ID code)、登入代碼(login code)、許可代碼(license code)等各種的名稱而被使用。
在本實施方式所謂的服務代碼，乃是對於從 提供者裝置3所發送完畢之有關用了使用API的服務應用 之服務的API利用要求，生成作為登錄伺服器10的資訊處理裝置來發行之代碼資訊。
此服務代碼，係對應到被登錄之個個的服務並作為唯一的代碼資料而被生成，至少與服務識別資訊及API使用資訊對應。
從而，服務代碼，係持有表示經由服務應用所被實行的服務作為API使用服務被正規登錄之功能。而且，服務代碼，也持有作為被使用到服務應用之服務實行時的認證之通行碼的功能。
含有這樣的功能或性質之代碼資料，無論該名稱為如何，是相當於本實施方式的“服務代碼”。
而且所謂許可資訊，乃是以服務代碼所被特定之服務中之對應到應用提供者所已指定的利用者特定資訊(亦即應用利用者)並以未承認狀態所被生成的代碼資料。而且，對應到應用利用者所被生成了的許可資訊，係持有所謂根據應用利用者的意思受理來自利用者裝置4的指示之許可承認之性質。許可的承認/不承認(或是未承認)的資訊，為作為許可承認資訊對應到許可資訊。
服務實行時的認證中，許可資訊是有確認對藉由在其服務中所使用的API所被存取的資訊的存取權限之意味。從而應用利用者在該服務中，也持有作為表示把API之資訊存取的權限給予到服務應用之代碼資料的功能。
含有這樣的功能或性質之代碼資料，無論該名稱為如何，是相當於本實施方式的“許可資訊”。
利用登錄伺服器10的功能被登錄到登錄資料庫30的資訊係具有如圖4般的關係。
尚且，圖4乃是把從服務代碼所見而被關連的各種資訊，不考慮該資料庫形式或連結形式、或者是資料構造等地予以揭示之圖。圖示之各資訊，可以相互直接關連，亦可透過其他的資訊間接地關連。
而且圖示之各資訊，可以彙集到1個資料庫而被登錄，亦可離散到複數個資料庫而被登錄。而且亦可在1個資訊內含有其他的資訊。例如，應用提供者的資訊被包含到作為服務識別資訊之代碼資料等。
無論是哪種形式，作為本實施方式的登錄資訊，係在已被關連的狀態下圖4的各資訊可以参照者為佳。
服務代碼，係與服務識別資訊、應用提供者的資訊關連著。
所謂服務識別資訊，乃是如上述般表示服務本身之代碼，例如因應作為服務應用的標題所被給予之1個服務識別資訊。具體方面，考慮到包含有作為服務應用的製品名稱、製品ID等之資訊；更進一步作為製品內容，亦可包含表示是否為實現哪樣的種類的服務之應用程式的內容資訊、或發行日期時間資訊、開發者資訊等。
而且例如在服務應用被予以版本升級的場合等，可以對每一版本給予相異的服務識別資訊，但作為完全相同標題的軟體，亦可賦與同一之服務識別資訊。但是，經由版本升級等，於至少API使用資訊為相異的場合，賦與相異 的服務識別資訊方為適切。
應用提供者的資訊，乃是表示作為應用提供者之個人或團體的資訊。
而且，於服務代碼，關連1個或是複數個API使用資訊。
所謂API使用資訊，乃是揭示該服務中所被使用的API之資訊。在圖中，作為API#1、API#2所揭示之2個API關連到服務代碼。此API使用資訊，係於登錄時應用提供者所指定。
而且，於服務代碼，關連1個或是複數個利用者特定資訊。利用者特定資訊，乃是表示個個的應用利用者之資訊。於登錄處理之際，以應用提供者指定1位或是複數位應用利用者的方式，表示該應用利用者的利用者特定資訊(MC-A、MC-B)關連到服務代碼。
更進一步，對應到各利用者特定資訊登錄許可資訊。例如許可資訊LC#A對應到利用者特定資訊MC-A。而且許可資訊LC#B對應到利用者特定資訊MC-B。個個的許可資訊(許可鑰LC#A、LC#B)，係作為各自相異之唯一的代碼值而被發行，並對應到各應用利用者。
尚且，說明上，把對個個的利用者特定資訊所發行之許可資訊，稱呼為「許可鑰」。
而且，於個個的許可資訊(許可鑰LC#A、LC#B)附帶許可承認資訊。此乃是，表示應用利用者是否已承認許可內容之資訊。
許可資訊，係當初以許可承認資訊=“未承認”的狀態而被發行。接著以應用利用者承認的方式，許可承認資訊被更新成“承認”。例如有關許可鑰LC#A，以利用者特定資訊MC-A所示之應用利用者賦與承認的方式，許可承認資訊變成“承認”。而且於應用利用者已拒絕承認的場合，許可承認資訊被更新成“不承認”。
如以上的圖4般，關連服務代碼與各種資 訊。所謂圖3之登錄資料庫30，乃是概念性表示在對應這樣一群的資訊的狀態下可以参照/更新之1或複數個資料庫。
各登錄資訊係並非得要以1個資料庫形態做整理保存，亦可分散儲存。而且，各登錄資訊之全部或是一部分，可以被保存到EC管理系統1的外部。
如圖3所示般，於EC管理系統1設有API伺 服器20。在API伺服器20，提供可以使用各種的API24(API#1、API#2，API#3...)。
各API24，可以為在EC管理系統1的內部而被開發者，亦可為藉由外部開發者而被開發者。接著，各API24本身，可以被準備在API伺服器20內，亦可被準備在外部的資訊處理裝置，API伺服器20來可以管理使用。
API24，乃是用以對例如API伺服器20所管理之各種資訊的存取之API。亦即，服務應用，係以使用API24的方式可以存取特定的資訊，可以進行資訊的参照或更新。
在此所謂可以讓API24做存取之各種資訊， 乃是例如為應用利用者之各商店之每一家的庫存資訊、商品價格資訊、營收資訊、顧客資訊，或是進行電子商務的管理營運之EC管理系統1側所作成之各商店向的統計資訊、販賣履歴資訊、管理資訊、會計資訊等。
這些資訊，乃是例如應用利用者之每一位之營業上的資訊，為欲限制公開的公開限制資訊。例如乃是考慮到尚未預設成商店A的工作人員把如上述般之自己的資訊給商店B等之其他人閱覧、更新等，或者是積極地予以秘密化之資訊。商店B也同樣，尚未預設成對商店B的工作人員來說，把自己營業上的資訊給商店A等之其他人閱覧。
所謂服務應用使用API24，係意味藉由實行該服務應用的方式進行公開限制資訊的閱覧或更新等。
例如某商店A(應用利用者)，從應用提供者購入庫存管理用的服務應用並予以導入，進行庫存管理。該服務應用，係使用API24，存取商店A的庫存資訊。從而，一定要防止被任意地使用、流出、盜用、或冒充利用此服務應用。因為其他人可以藉由實行該服務應用，進行商店A的公開限制資訊的閱覧或更新等。
對其他的商店B來說也是同樣，在導入某服務應用的場合，藉由該服務應用透過API24存取商店B營業上的資訊的緣故，確保該服務的正當利用是有必要。
更進一步，期望即便發生了未授權使用，也可以把受害抑制再最小限度。
為此於實行服務應用，加上商店A的意思之承認或限 制者較為適合。後述的是，在本實施方式中考慮到這樣的問題點，進行有關許可資訊的應用利用者之承認。
尚且在圖3等，作為說明上的方便，把保存 有API24存取這樣的資訊(作為其中一例，為各商店營業上的資訊)之記憶部位，作為商店資訊資料庫31予以概念性的表示。各資訊並非得要以資料庫形態做整理保存。而且，各資訊可以被保存到EC管理系統1的外部。
於API伺服器20，設有認證部21。
認證部21具備作為認證處理部21a及登錄資訊取得部21b的功能。
尚且、認證處理部21a乃是表現有進行認證處理的功能、登錄資訊取得部21b乃是表現有對登錄資料庫30存取而取得用在認證的登錄資訊的功能。實際上認證處理部21a與登錄資訊取得部21b，係藉由個個的程式所實現，或者是藉由作為已關連之複數個程式所實行之功能所實現。更進一步可以掌握分別揭示了1個程式中所實行的認證處理與登錄資訊取得處理。
認證部21，係在例如利用者裝置4中實行服務應用，在對API伺服器20要求了API使用之際，進行對該API使用要求的認證。
為此認證部21，係利用認證處理部21a的功能，取得有關API使用要求的服務代碼與許可資訊(許可鑰)。後述的是，於服務實行時隨著使用要求發送服務代碼與許可資訊(應用利用者已承認的許可鑰)。認證部21取得 此發送之服務代碼與許可鑰。
而且認證部21，係利用作為登錄資訊取得部21b的功能，存取登錄資料庫30，取得於認證所必要的資訊。 具體方面，使用API使用要求之服務代碼與許可資訊，取得於圖4所示之登錄資訊。例如，對應到有關該認證對象的服務之服務代碼的服務識別資訊，取得API使用資訊、應用提供者的資訊、或對應到許可資訊(此次所用的許可鑰)之許可承認資訊等。
接著認證部21，係利用認證處理部21a的功能，進行至少包含服務代碼、API使用資訊、及許可承認資訊的對照之認證處理，因應認證結果進行許可已被要求的API使用之處理。
於API伺服器20，設有實際工時管理部22。
實際工時管理部22，係在經由在認證部21的認證處理許可了API使用之場合，根據API使用要求之服務代碼，生成應用提供者的實際工時資訊，而且根據許可資訊，進行生成應用利用者的實際工時資訊之處理。
藉由服務代碼特定應用提供者。而且，於許可資訊(此次所用的許可鑰)，以對應著利用者特定資訊的方式，可以辨識應用利用者。從而、有關API使用實際工時，可以分別對應用提供者與應用利用者生成、更新實際工時資訊。
所謂實際工時資訊，乃是例如API使用資訊、對API使用之會計資訊等。
所謂API使用資訊，可以是服務應用所致API使用要求次數或使用要求日期時間、使用履歴等所可以掌握的資訊，亦可是實際上使用了API之存取的次數(讀出次數/更新次數)、日期時間、履歴等所可以掌握的資訊。而且也考慮到對API使用要求之認證結果的履歴資訊等。
作為會計資訊，預設有因應API使用要求而被會計之會計資訊、因應API之資訊存取而被會計之會計資訊、或者是因應實際工時次數的階段而被設定之會計資訊等，各種的會計資訊。
說明上，把保存各應用提供者或各應用利用 者的實際工時資訊之部位作為實際工時資料庫32來概念性的表示。各種的實際工時資訊並非得要以資料庫形態做整理保存。而且，實際工時資訊可以被保存到EC管理系統1的外部。
尚且，具備了作為認證部21、實際工時管理 部22的功能部位之資訊處理裝置，係可與作為API伺服器20的資訊處理裝置成為一體，亦可以與作為API伺服器20的資訊處理裝置為不同體的資訊處理裝置而被構成。
而且具備了認證部21之資訊處理裝置與具備了實際工時管理部22之資訊處理裝置亦可為不同體。
更進一步，具備了作為登錄伺服器10的功能部位之資訊處理裝置、與作為API伺服器20的資訊處理裝置，係可為一體，亦可以不同體之資訊處理裝置而被構成。
<3．登錄時的處理>
在如上述般於圖1所示之網路系統中，應用提供者把使用藉由API伺服器20所被準備好的API之服務應用提供給應用利用者；應用利用者享受提供的應用程式的實行所帶來的服務。
在本實施方式中，作為此服務實行的前提，首先服務(服務應用)要求被正規登錄到EC管理系統1中。具體方面，進行有關某服務中服務代碼的發行及登錄、許可資訊的發行及登錄、更進一步許可承認資訊的登錄。以下，詳述有關此登錄處理。
圖5為示意性的表示用以登錄處理的關連部 位與資訊的交換。於一連串的登錄處理，關係到應用提供者(提供者裝置3)、應用利用者(利用者裝置4)、登錄伺服器10，實行對登錄資料庫30之登錄資訊的寫入、更新。
大致上以接下來(R1)~(R7)的順序進行 登錄處理。
(R1)應用提供者，係從提供者裝置3，利用提供者WEB12對登錄伺服器10，進行有關某服務(服務應用)的API使用登錄要求(進行API使用的服務的登錄要求)。
(R2)登錄伺服器10生成服務代碼，對提供者裝置3進行發行的同時，於登錄資料庫30使其與服務代碼對 應登錄到有關服務的資訊。
(R3)應用提供者，係從提供者裝置3，利用提供者WEB12對登錄伺服器10，通知利用者特定資訊作為許可發行要求。尚且，所謂於此場合進行通知之利用者特定資訊，作為其中一例，考慮有顯示以與應用提供者之間的服務利用契約等預定該服務的利用之應用利用者、或者是應用提供者預設有服務提供之應用利用者等之資訊。當然，可以因應應用利用者對應用提供者請求許可發行，應用提供者把顯示該應用利用者之利用者特定資訊通知到登錄伺服器10。
(R4)登錄伺服器10係對應到利用者特定資訊發行許可資訊(許可鑰)，把這些關連到服務代碼登錄到登錄資料庫30。
(R5)登錄伺服器10，係對許可資訊所發行的應用利用者(利用者裝置4)，進行許可發行通知。
(R6)應用利用者，係從利用者裝置4利用有利用者WEB13，確認許可內容，把選擇了承認/不承認之許可承認資訊發送到登錄伺服器10。
(R7)登錄伺服器10，係根據應用利用者的意思接收許可承認資訊，在承認的場合，把作為許可資訊之唯一的代碼之許可鑰發送到利用者裝置4。而且，無關於承認/不承認，使許可承認資訊對應到許可資訊，登錄到登錄資料庫30。
登錄處理係如以上所述；已被登錄的服務， 係在最終得到了許可鑰的“承認”著場合，藉由做了該承認之應用利用者而可以實行。
以下，參閱圖6~圖14說明作為登錄處理之各部之具體的處理例。
圖6係主要表示提供者裝置3與登錄伺服器10之處理。
尚且，以下，所謂在圖6~圖8所示之登錄伺服器10的處理，乃是登錄管理部10使用在圖3所說明過的服務代碼處理部11a、許可處理部11b的功能，而且使用提供者WEB12、利用者WEB13進行實行之處理。
進行實現某服務之服務應用的提供(例如讓 渡或出借)之應用提供者，係首先為了該服務的登錄，使用提供者裝置3，存取登錄伺服器10所準備之提供者WEB12。
有關提供者裝置3，作為步驟S1，使用被應用提供者所賦與的登入通行碼、使用者ID等，登入到提供者WEB12。
經由登入，登錄伺服器10，係以步驟S100辨 識應用提供者。接著，登錄伺服器10，係因應例如來自提供者裝置3側之全球資訊網上的要求操作，在步驟S101，於提供者WEB12中提供用於API使用登錄要求之畫面(全球資訊網頁)。
於圖9表示在提供者WEB12上所提供之API使用登錄畫面70之例。在此API使用登錄畫面70，為了應用提 供者的輸入或操作，準備有：製品資訊輸入部71、使用API輸入部72、登錄操作部73、返回操作部74、登出操作部75、API選擇操作部76等。
在製品資訊輸入部71，可以輸入作為所提供之服務應用的製品ID、製品名稱、摘要(服務內容的摘要)、解說頁URL、製品URL等。
在使用API輸入部72，可以輸入該服務應用所使用之API。例如操作API選擇操作部76，表示API清單，可以從該清單選擇API。因應選擇，被使用API輸入部72記入有API名稱或處理內容。
應用提供者係從提供者裝置3，對這樣的API使用登錄畫面70進行操作，進行API使用登錄要求。
具體方面，應用提供者係使用提供者裝置3，閱覧API使用登錄畫面70，輸入必要事項。接著，例如於圖9所示般，在進行過製品資訊輸入部71、使用API輸入部72的輸入的狀態下，操作登錄操作部73(點選)。經此，作為步驟S2，根據輸入內容，API使用登錄要求從提供者裝置3被發送到登錄伺服器10。
有API使用登錄要求的話，登錄伺服器10係在步驟S102，取得有關API使用登錄要求之資訊。亦即把被API使用登錄畫面70的製品資訊輸入部71所輸入的資訊之全部或是一部分，作為服務應用的識別資訊(服務識別資訊)而予以取得。在一部分的場合，把例如製品ID、製品名稱、摘要包含到服務識別資訊。
而且，登錄伺服器10，係把被API使用登錄畫面70的使用API輸入部72所輸入過的各API的資訊，作為API使用資訊而予以取得。
更進一步登錄伺服器10，係對1個API使用登錄要求，生成乃是唯一的代碼之服務代碼。
繼續，登錄伺服器10係在步驟S103，進行對登錄資料庫30之登錄。在此時點，對應到已生成之服務代碼，關連在步驟S102所取得到的服務識別資訊與API使用資訊、以及在步驟S100辨識過的應用提供者的資訊，並予以登錄。
在步驟S104，登錄伺服器10把服務代碼通知到提供者裝置3。例如，在提供者WEB12中，提示例如圖10般的登錄完畢畫面80。
在登錄完畢畫面80，表示有：服務代碼提示部81、服務內容提示部82、使用API提示部83、返回操作部84、登出操作部85等。
於服務代碼提示部81，表示例如數10位數程度之乃是唯一代碼之服務代碼。
於服務內容提示部82，表示對應到該服務代碼而被登錄過的服務應用的內容(服務識別資訊的內容)。
於使用API提示部83，表示作為該服務應用所使用而被登錄之API。
應用提供者，係以閱覽這樣的登錄完畢畫面80的方式，可以確認完畢了有關服務之適當的登錄。
接著，在步驟S3，提供者裝置3取得提示過的服務代碼。
至此為止，因為完畢了與登錄伺服器10之交換。提供者裝置3係在步驟S4從提供者WEB12進行登出。
但是，亦可不登出地，進行在圖7所述之有關許可資訊的處理。
尚且、在圖6表示有作為步驟S5、S6之提供 者裝置3的處理；但該步驟S5、S6可以並非得要以此登錄處理的過程來進行。
在步驟S5，提供者裝置3把服務代碼附加到服務應用。亦即把服務代碼埋入到作為所提供的製品之服務應用，於服務利用時使用服務代碼。
在步驟S6，從提供者裝置3提供服務應用到利用者裝置4。例如把完畢了服務代碼的埋入之服務應用下載到利用者裝置4。或者是應用提供者乃是作為ASP的業者的話，可以把服務應用所可以使用的部分通知到應用利用者。
此步驟S5、S6，到底是在應用提供者的業務之一環下所進行者，至少在接受服務代碼的發行後任意地進行者為佳，並非EC管理系統1所關與者。
繼續，應用提供者，係有關許可資訊的發 行，於登錄伺服器10進行求取。
作為圖7的步驟S10，提供者裝置3係使用被應用提供者所賦與的登入通行碼、使用者ID等，登入到提供者 WEB12。
經由登入，登錄伺服器10，係以步驟S110辨識應用提供者。
接著，登錄伺服器10係因應例如來自提供者裝置3側之全球資訊網上的要求操作，在步驟S111，於提供者WEB12中提供用於許可發行之畫面(全球資訊網頁)。
於圖11表示在提供者WEB12上所提供之許可發行畫面90之例。在此許可發行畫面90，顯示有：製品清單表示部91、商店指定部92、追加操作部93、許可發行對象清單94、刪除操作部95、許可發行操作部96、返回操作部97、登出操作部98等。
登錄伺服器10，係於製品清單表示部91，把 作為此次已登入之應用提供者的製品而登錄中的服務應用予以進行清單表示。
在商店指定部92，可以指定作為應用利用者之店家的輸入。例如經由可以特定對EC管理系統1所管理中的店家所賦與的ID(以下稱為「店家ID」)、或者是店家的郵件位址、其他店家或店家的聯絡處之資訊，而可以指定。
於許可發行對象清單94，有關例如製品ID或以製品名稱所表示之某服務應用，可以把作為許可發行對象之應用提供者(商店)予以列表。
應用提供者係從提供者裝置3，對這樣的許可 發行畫面90進行操作進行許可發行要求。
具體方面，應用提供者係使用提供者裝置3，閱覧許可發行畫面90，輸入必要事項。
首先在製品清單表示部91確認自己的製品的清單，選擇進行此次許可發行要求之製品。
而且對商店指定部92，輸入把1家或是複數家商店(應用利用者)予以特定之資訊。再加上以操作追加操作部93的方式，有關已指定之製品(服務應用)中已輸入到商店指定部92之應用利用者，為作為許可發行對象被追加到許可發行對象清單94。
一旦即便是載到許可發行對象清單94，也可以使用刪除操作部95從清單上予以排除。
應用提供者，係可以把例如已服務提供之契約完畢的商店、或預定服務利用的商店等，以商店指定部92予以指定並記入到許可發行對象清單94。
應用提供者，係在使必要的許可發行對象記 入到許可發行對象清單94的狀態下，操作許可發行操作部96。經此，作為步驟S11，根據輸入內容，許可發行要求從提供者裝置3被發送到登錄伺服器10。
有許可發行要求的話，登錄伺服器10係在步 驟S112，取得有關許可發行要求之資訊。亦即根據被記入到許可發行畫面90的許可發行對象清單94之資訊，取得把對服務應用求得了許可發行之利用者予以特定之利用者特定資訊。例如把店家ID作為利用者特定資訊而取入。
接著，登錄伺服器10，係發行有關1個或是複數個利用者特定資訊之各個的許可資訊(許可鑰)。
繼續，登錄伺服器10係在步驟S113，進行對 登錄資料庫30之登錄。此場合，係就此次的要求之服務應用，使其對應到已經登錄中的服務代碼，登錄1個或是複數個利用者特定資訊與許可資訊的設定。但是，有關已發行之許可資訊，在該時點，附加有表示“未承認”之許可承認資訊。
在步驟S114，登錄伺服器10對提供者裝置3通知許可發行完畢。例如，在提供者WEB12中，提示許可發行完畢畫面。
應用提供者，係以閱覽許可發行完畢畫面的方式，可以確認完畢了有關各個已指定之應用利用者的許可發行。
至此為止，因為完畢了與登錄伺服器10之交換。提供者裝置3係在步驟S12從提供者WEB12進行登出。
在至此為止的處理，作為有關應用提供者所 提供之服務的登錄資訊，服務識別資訊與應用提供者被對應到服務代碼，而且該服務中，利用所被預設之應用利用者的利用者特定資訊、與有關該應用利用者所已被發行的許可資訊，為已對應的狀態。但是，在該時點，許可資訊中，被附加著被做成“未承認”之許可承認資訊。
之後，登錄伺服器10，係在與利用者裝置4之間，進行有關許可承認之處理。
圖8係表示有關許可承認之利用者裝置4與 登錄伺服器10之處理例。
登錄伺服器10，係在如上述般進行過許可發行之場合，作為步驟S120，根據對應到已發行之許可資訊之利用者特定資訊，對利用者裝置4通知許可發行的事實。
例如EC管理系統1，係附帶店家ID與電子郵件位址來進行管理，而且作為利用者特定資訊，使用店家ID。該場合，登錄伺服器10係從店家ID取得應用利用者的電子郵件位址，進行許可發行通知給該電子郵件位址。應用利用者經由此通知，可以辨識已有新的、與自己相關連之許可發行。
應用利用者係使用利用者裝置4對利用者WEB13進行存取，可以進行有關許可的確認或操作。
有關利用者裝置4，作為步驟S300，使用被應用利用者所賦與的登入通行碼、使用者ID等，登入到利用者WEB13。
因應登入，登錄伺服器10係在步驟S121，辨識應用利用者，把有關該應用利用者之許可清單畫面提供在利用者WEB13上。
於圖12表示許可清單畫面120之例。在許可清單畫面120，顯示有：把有關該應用利用者所發行中之許可的清單予以顯示之許可清單表示部121、刪除操作部123、登出操作部124等。
在許可清單表示部121，顯示被視為對象之該應用利用者的發行完畢的許可資訊的內容。例如應用提供者的公 司名、可以組合到服務識別資訊之製品名稱、許可發行日、承認/未承認的狀態等。
應用利用者係在此許可清單表示部121內，選擇進行有關承認的操作之許可資訊。
尚且，使用刪除操作部123，也可以從許可清單刪除特定的許可。
經由應用利用者的許可選擇操作，作為步驟 S301，從利用者裝置4對登錄伺服器10發送許可選擇的資訊。對應於此登錄伺服器10係在步驟S122，把如圖13般的許可承認操作畫面130提示在利用者WEB13上。
在許可承認操作畫面130，顯示有：製品資訊表示部131、API清單表示部132、承認操作部133、承認拒絕操作部134、返回操作部135、登出操作部136、提醒注意訊息137等。
於製品資訊表示部131，表示有關該許可資訊 之服務的內容。例如，作為應用提供者之公司名、服務應用的製品名稱、服務內容的摘要、許可發行日等。應用利用者經此可以理解該許可為有關哪樣的服務。
經由提醒注意訊息137，提示此服務所使用的 API，於API清單表示部132，表示實際上所使用的API。此提醒注意訊息137與API清單表示部132的資訊，係對應用利用者，持有作為顯示隨服務實行的風險之風險資訊的意味。
在API清單表示部132，表示在該服務所使用的API 名稱、與所表示之該內容。藉由內容，被表示有各API 存取到哪樣的資訊，是否進行資訊的取得或資訊的更新等。
應用利用者，係經由此表示，可以辨識伴隨服務實行之危險性，具體方面是有關自己的商店的資訊的危險性。
尚且，作為風險資訊，有關更進一步藉由API所被讀出或更新之資訊的類別、內容等，可以表示有更具體的內容。例如也可以提示藉由各API所被存取之價格資訊、庫存資訊、顧客名簿資訊等之具體的資訊。而且也可以表示有隨著API使用之資訊流出的具體例等。
應用利用者在辨識到了API使用所帶來的危 險性之下，對於許可資訊可以選擇予以承認或是予以拒絕承認。
作為許可承認的手法，考慮有：概括承認、個別承認。
所謂概括承認，乃是應用利用者把使用提示中的全部API這一點作為前提，登錄伺服器10僅就承認許可予以受理之手法。
所謂個別承認，乃是應用利用者在提示著的API中，登錄伺服器10許容所謂僅承認一部分的使用之許可承認之手法。
首先說明有關採用概括承認的場合。
應用利用者可以確認許可承認操作畫面130，僅在同意了有關全部的API所使用的之下，進行承認操作部133 的操作。
例如，如圖示般，就各API準備查核方塊，僅在就全部的API被查核過的場合，承認操作部133成為有效(active)。
應用利用者在承認有關許可資訊的場合，操作承認操作部133。另一方面，考慮到危險性而不承認的場合，操作承認拒絕操作部134。
經由這些的操作，作為圖8的步驟S302，從利用者裝置4對登錄伺服器10通知許可承認資訊。
登錄伺服器10係在步驟S123，取得表示“承 認”或是“不承認(承認拒絕)”的許可承認資訊。接著，在步驟S124，作為對應到對象的許可資訊之許可承認資訊，登錄到登錄資料庫30。
該場合，以概括承認的方式，在承認了該許可資訊的場合，把該服務中API使用資訊所登錄之全部的API使用，成為應用利用者已承認的。
採用個別承認的場合係如下述般。
應用利用者，係確認許可承認操作畫面130，選擇是否承認有關各API所使用的。接著，例如有關同意了使用之一部分或是全部的API，在於查核方塊進行過查核之下，操作承認操作部133。在不承認全部的API的使用之場合，操作承認拒絕操作部134。
經由這些的操作，作為圖8的步驟S302，從利用者裝置4對登錄伺服器10通知許可承認資訊。
登錄伺服器10係在步驟S123，於每個API， 取得表示“承認”或是“不承認(承認拒絕)”的許可承認資訊。接著，在步驟S124，作為對應到對象的許可資訊之許可承認資訊，登錄到登錄資料庫30。
該場合，使許可資訊對應，登錄有關API使用資訊所列舉之各API之承認/不承認。
尚且，一部分的API為“不承認”的話，變成該服務中，不使用該API。亦即，變成應用利用者可以限制服務應用之一部分的功能。
在步驟S124，進行過許可承認資訊的登錄的 話，登錄伺服器10係對利用者裝置4進行承認結果通知。
例如，在以概括承認進行了承認之場合，或者是以部分承認進行了一部分或是全部的API的承認之場合，登錄伺服器10係在提供者WEB12中，提示例如圖14般之許可承認結果畫面140。
在許可承認結果畫面140，顯示有：例如服務表示部141、許可鑰表示部142、返回操作部143、登出操作部144等。
在服務表示部表示服務應用的應用提供者或製品名稱，有關該已承認的許可鑰被許可鑰表示部142所表示。
應用利用者，係以閱覽這樣的許可承認結果畫面140的方式，可以確認完畢了有關服務之許可承認。
接著，在步驟S303，利用者裝置3取得提示過的許 可鑰。該許可鑰，係保存作為之後實際上使用服務應用之鑰。
至此為止，因為完畢了與登錄伺服器10之交換。利用者裝置4係在步驟S304從利用者WEB13進行登出。
尚且，在許可承認拒絕的場合，登錄伺服器 10係在利用者WEB13上提示許可拒絕(不承認)的結果。
利用者裝置4即便一旦拒絕了之後，以圖12的許可清單表示部121再度選擇該服務，可以進行許可承認。
從以上的圖6經由圖8的處理而已被登錄的 服務應用，係可以實行使用了之後的API的處理。在該時點，關於服務應用，遂形成於圖4所示之登錄資訊。
<4．服務實行時之處理例I>
繼續，說明服務實行時的處理例。
尚且，關於處理例I、處理例II、處理例III，作為應用利用者，係把利用圖1的提供者裝置3A者、亦即作為應用程式的套件，預設成利用下載或媒體提供到利用者裝置4者進行說明。接著，後述的處理例IV，係預設作為利用圖1的提供者裝置3B之ASP的業者的場合。
首先，參閱圖15~圖18，說明處理例I。
圖15為示意性的表示有關服務實行時的認證或API使用的處理之關連部位與資訊的交換。
該場合，於利用者裝置4，從提供者裝置3A提供服 務應用。亦即，於利用者裝置4中，安裝作為服務應用的程式，成為可以啟動的狀態。
應用利用者，係在利用者裝置4中啟動服務應用，享受該服務應用所帶來之服務、例如商品管理、庫存管理、顧客管理等地服務的結果。於此之際，服務應用係使用API伺服器20所準備的API，進行必要的資訊存取。
服務實行時的處理係大致上以接下來的(P1)~(P4)的順序進行。
(P1)根據已啟動的服務應用，利用者裝置4係對API伺服器20發送API使用要求(使用了API的資訊存取實行之要求)。於該場合也發送服務代碼與許可鑰。
(P2)API伺服器20，係利用認證部21的功能，根據隨API使用要求的服務代碼與許可鑰進行認證處理。接著，把認證結果通知到利用者裝置4。
(P3)認證OK的場合，API伺服器20係利用實際工時管理部22的功能，根據服務代碼與許可鑰，就應用提供者與應用利用者，進行個別的實際工時管理處理。
(P4)認證OK的場合，API伺服器20許可API使用。亦即，因應在服務應用所致的處理過程所發生的要求，實行API使用。
以下，說明服務實行時之各部之具體的處理例。
圖16係主要表示利用者裝置4與API伺服器20的處理。
尚且、所謂在圖16~圖18所示之API伺服器20的處理，係包含：使用認證部21以圖3所說明之認證處理部21a、登錄資訊取得部21b的功能而實行的處理、與實際工時管理部22的功能所致之處理、與API24所致之處理。
應用利用者利用自己的利用者裝置4實行服 務應用的場合，首先在利用者裝置4，作為圖16的步驟S320，進行服務應用的啟動處理。
尚且、於服務應用的啟動之際，求得對應用利用者輸入許可鑰。實際上，可以於利用者裝置4內的指定處(服務應用所可以參閱之特定資料夾等)事先記憶許可鑰，於啟動時服務應用可以取得該許可鑰。
而且，服務應用係在應用提供者側，在埋入了服務代碼的狀態下，經由透過網路2的下載、或記憶媒體之傳輸，被應用利用者所提供，被利用者裝置4所安裝。於服務應用之啟動時，也取得此服務代碼。
以啟動服務應用的方式，藉由該服務應用作 為所被規定的處理，在利用者裝置4進行步驟S321之後的處理。
在步驟S321，利用者裝置4對API伺服器20發送API使用要求。
於該API使用要求之際，利用者裝置4也同時發送服務代碼與許可鑰。
尚且，於API使用要求，也包含顯示進行過要求的服 務應用之服務識別資訊、及指定成為使用要求的對象的API之資訊。
API伺服器20係因應API使用要求在步驟 S400，利用認證部21的功能進行認證處理。表示此認證處理與圖17。圖17，乃是藉由具有作為認證處理部21a、登錄資訊取得部21b的功能之認證部21所實行之處理者。
認證部21係在圖17的步驟S410，與API使用要求一起取得從利用者裝置4所發送完畢的服務代碼與許可鑰。
而且，認證部21，也取得表示作為API使用要求的資訊所包含之服務識別資訊與使用要求對象的API之資訊。
繼續，認證部21係在步驟S411，使用服務代 碼與許可鑰存取到登錄資料庫30，取得對應到該服務代碼及許可鑰之登錄資訊。用圖4說明的話，作為對應到服務代碼的登錄資訊，取得服務識別資訊、應用提供者的資訊、及API使用資訊。而且作為對應到許可鑰之登錄資訊，取得對應到該許可鑰本身之利用者特定資訊及許可承認資訊。例如，許可鑰LC#A的場合、取得有關利用者特定資訊MC-A、及許可鑰LC#A之許可承認資訊。
在步驟S412，認證部21確認系統錯誤。例 如，因為系統上的硬體所致的原因、通訊系統或傳送路徑的原因、其他的動作錯誤等，無法適切進行登錄資訊的讀 入之場合，發生系統錯誤。該場合下，前進到步驟S419，最終判定成不能認證。
在不發生系統錯誤，可以正常做登錄資訊存取的場合，移到實際的認證處理。
首先，在步驟S413，認證部21進行有關服務代碼的認證。例如，進行以下的確認。
．確認是否為正規已登錄之服務代碼
確認與API使用要求一起發送完畢之服務代碼，是否為被登錄資料庫30所已登錄的服務代碼。
．確認登錄資訊存在
根據服務代碼，適切地事先登錄服務識別資訊、應用提供者的資訊、及 API使用資訊，確認可否取得。
例如，以上的確認為OK的話，服務代碼為認證OK，任一個不滿足的話服務代碼為認證NG。
在步驟S414，認證部21進行有關使用API的認證。例如，進行以下的確認。
．確認使用API的一致
確認API使用要求中做為使用要求對象之API、與以登錄資訊的API使用資訊所示之API，是否為一致。尚且，可以僅把複數個API之完全一致作為OK；但於API使用要求中成為使用要求對象之1個或是全部複數個API，被登錄資訊的API使用資訊所揭示的話，也是可以為OK。
．確認API可以使用狀態
在EC管理系統1上，是有API因任何的事情而不可使用，或者是因維修等而停止使用的場合。例如，API伺服器20，係於所提供之各API中，管理這樣的狀況。在此API使用要求中，確認作為使用要求對象之1個或是複數個API現在是否可以使用。
例如，以上的確認為OK的話，有關使用API為認證OK；任一個不滿足的話，有關使用API為認證NG。
在步驟S415，認證部21進行服務識別資訊的認證。例如，進行以下的確認。
．確認與登錄資訊一致
確認API使用要求中所示之服務識別資訊、與根據服務代碼所讀出之登錄資訊的服務識別資訊是否為一致。亦即，確認發送了此次API使用要求之服務應用，是否為正規已登錄之服務應用。
例如，以上的確認為OK的話，服務識別資訊為認證OK；任一個不滿足的話，有關服務識別資訊為認證NG。
在步驟S416，認證部21進行有關許可鑰的認證。例如，進行以下的確認。
．確認許可鑰的正當性
確認API使用要求中發送完畢的許可鑰與服務代碼，是否也作為登錄資訊而被關連，亦即，確認許可鑰是否為對應到該服務應用而正當地已被登錄者。
．確認許可承認
確認對應到API使用要求中已發送完畢之許可鑰而從 登錄資料庫30讀出之許可承認資訊。
例如，以上的確認中，許可鑰的正當性為OK，而且許可承認資訊為顯示“承認”的資訊的話，許可鑰為認證OK。另一方面，正當性是否為NG、或是許可承認資訊為“未承認”或者是“不承認”的話，許可鑰為認證NG。
在全部的步驟S413~S416，於為認證OK的場合，認證部21前進到步驟S418，最終為認證OK。
另一方面，在任一步驟S413~S416，於為認證NG的場合，認證部21前進到步驟S417，最終為認證NG。
經由這樣的認證，確保隨服務應用所致的API使用的資訊的安全性。
經由服務代碼認證，服務應用為藉由應用提供者確認所謂正確已被登錄之正當性，經由API使用資訊的認證，確認作為所使用的API的範圍之權限。而且，經由許可資訊，確認與應用提供者的關係之應用利用者的正當性、與作為應用利用者的承諾的範圍之API使用。為此、在應用提供者與應用利用者之2者的意思所致的合意範圍內，確保服務應用所致之正當的API使用。
為此，適合進行至少包含服務代碼、API使用資訊、及許可承認資訊的確認之認證處理。
以上的認證處理為其中一例。也並非得一定要實行上掲之全部的事項的認證。例如，作為登錄資訊對應到服務代碼，也可以不用進行是否得到應用提供者的資訊之確認。
但是，有關全部之步驟S413~S416的服務代碼、服務識別資訊、API使用資訊、及許可鑰在上述的確認為可以的場合成為最終認證OK的話，是適合在服務實行時的資訊的安全性方面。
而且，可以加上其他事項的認證。例如，於API使用要求之際，也發送應用提供者的資訊的話，也可以確認有關應用提供者的資訊與登錄資訊一致。
同樣，於API使用要求之際，顯示應用利用者的資訊被發送的話，也可以確認與對應到許可鑰利用者特定資訊的一致。
在圖16的步驟S400，進行例如以上的圖17 般的認證處理。
得到認證結果的話，API伺服器20在步驟S401對利用者裝置4進行認證結果通知。亦即，通知圖17的步驟S416或是在S417得到的認證OK、認證NG、或者是不能認證。
變成認證NG或是不能認證的場合，API伺服 器20，從圖16的步驟S402前進到S405，作為API使用禁止，對API使用要求結束處理。
而且，在利用者裝置4，在接收了認證NG或是不能認證的通知的場合，從步驟S322前進到S324，服務應用變成錯誤結束。
在成為認證OK的場合，API伺服器20從步 驟S402前進到S403，進行實際工時管理部22的功能所 致之實際工時管理處理。表示此實際工時管理處理於圖18。實際工時管理部22，係例如從認證部21，對應通知認證OK的結果，使用服務代碼、許可鑰，進行實際工時管理處理。
於圖19，表示被實際工時資料庫32記憶之實際工時資訊之其中一例。
作為有關應用提供者的實際工時資訊，於每一各應用提供者V1，V2...，記憶API使用實際工時。
例如，於每發生API使用時，進行記憶日期時間、顯示使用API的資訊、顯示應用程式的資訊、顯示應用利用者的資訊、會計資料。
有關應用利用者的實際工時資訊，也是同樣，於每一各應用利用者M1，M2...，記憶API使用實際工時。
例如，於每發生API使用時，進行記憶日期時間、使用API、顯示應用程式之資訊、顯示應用提供者、會計資料。
作為顯示使用API之資訊，係可以使用從服務代碼所導入的API使用資訊。
顯示應用程式之資訊，係可以使用從服務代碼所導入的服務識別資訊。
顯示應用利用者之資，係可以使用從許可鑰所導入的利用者特定資訊。
顯示應用提供者之資訊，係可以使用從服務代碼所導入的應用提供者的資訊。
會計資料乃是對應所使用的API之單價、或累積金額等。
實際工時資訊係不限於如該圖19般之例，也預設其他多樣應記憶的項目，無論如何，只要是可以掌握API的使用實際工時、或對應於此之會計金額者即可。
實際工時管理部22，係對於例如這樣的應用提供者之實際工時資訊、與應用利用者的實際工時資訊，進行更新/追加等。
在圖18的步驟S431，實際工時管理部22，係從服務代碼，判定應用提供者V(x)、服務識別資訊、API使用資訊。這些係可以作為認證時所讀出的登錄資訊而取得，亦可實際工時管理部22存取登錄資料庫30而取得。
在步驟S432，實際工時管理部22進行應用提供者的API使用資訊的更新。例如，於有關從服務代碼所導入的應用提供者V(x)之如圖19般的實際工時資訊，追加有關此次的API使用要求之日期時間、使用API、服務識別資訊、利用者特定資訊。
而且，在步驟S433，實際工時管理部22，係生成對有關此次的API使用要求的應用提供者之會計資料。接著，把會計資料追加到實際工時資訊。
在步驟S434，實際工時管理部22係以從許可鑰所導入的利用者特定資訊判定應用使用者M(x)。利用者特定資訊，係可以作為認證時所讀出的登錄資訊而取得，亦可實際工時管理部22存取登錄資料庫30而取得。
在步驟S435，實際工時管理部22進行應用利用者的API使用資訊的更新。例如，於有關以利用者特定資訊所被特定之應用利用者M(x)之如圖19般的實際工時資訊，追加有關此次的API使用要求之日期時間、使用API、服務識別資訊、應用提供者的資訊。
而且，在步驟S436，實際工時管理部22，係生成對有關此次的API使用要求的應用利用者之會計資料。接著，把會計資料追加到實際工時資訊。
作為圖16的步驟S403之實際工時管理處理，例如以進行如以上之圖18般之方式，有關API使用，可以分別對應用提供者、應用利用者進行實際工時管理或會計資料形成，可以容易掌握API使用的關係者的實際工時。而且，為經過認證下的使用的緣故，實際工時資訊係確保有關正當的API使用之實際工時，在該意味下，分別對應用提供者、應用利用者之會計資料也作為有關正當的API使用之金額而可以計算決定。
尚且，圖18只不過是其中一例。實際工時資訊的資料形態係預設為多樣。因應設定之實際工時資料的資料類別、資料庫形式等，必要的實際工時資訊的追加或更新，可以分別就應用提供者與應用利用者來進行。
而且，實際工時管理，並不只於認證OK的場合包括性的登錄使用實際工時這樣的手法，也考慮到在應用程式所致之服務實行中的處理過程登錄實際上每次使用API、使用實際工時之這樣的手法。
上述之認證OK的場合，在利用者裝置4，從步驟S322前進到S323，實行服務應用之通常處理。
在該服務應用的處理過程，使用API伺服器20所準備著的API，進行有關應用利用者之資訊存取。在API伺服器20側，因應服務應用的要求，如作為步驟S404所示般進行API處理，實行對商店資訊資料庫31之資訊存取。
例如，如圖15所示般，於商店資訊資料庫31，就各應用利用者M1，M2...，保存著各應用利用者的營業資訊M1dt、M2dt...等。
現在，於圖15所示之利用者裝置4，為作為應用利用者M1所用之裝置的話，藉由服務應用的處理，利用者裝置4利用例如API#1，對自己的營業資訊M1dt進行存取。
利用這樣的存取，服務應用係在利用者裝置4上對應用利用者M1，進行商品庫存、價格管理、顧客資訊等的提示、編集對應等。亦即，提供網路服務。
接著，這樣的API使用所致之資訊存取，係在上述般使用了服務代碼與許可鑰之認證下而實行。從而，不用過度地進行API使用，以被限制在正當的使用之範圍的方式，也確保營業資訊M1dt等的資訊的安全性。
尚且，經由許可鑰的認證特定應用利用者的緣故，可以限定經由API所處理的資料。例如，在來自應用利用者M1的利用者裝置4之API使用的場合，可以例如經由 API#1對營業資訊M1dt存取，卻無法對他人的營業資訊M2dt存取。實際上，API#1根據認證結果，可以進行過濾使得僅存取認證過的應用利用者M1向的資訊。在如此為之的方式下，對各應用利用者M1、M2...來說，對自己的營業資訊進行存取而可以閱覧、更新等，而且，該自己的營業資訊透過他人是無法存取的。
亦即，預設了處理具有利用者限定性的資訊之API的場合，為適合根據許可鑰的認證結果，限定API所存取的資訊。
但是，在API處理未特別被利用者限定之一般公開資訊的場合，亦可不用進行把進行這樣的存取之資訊對應到應用利用者而予以限定般之資訊的過濾。
順便一說，先前有關應用利用者所致之許可承認，乃是就使用API之概括承認與個別承認予以闡述。
包含至此為止的認證或實際工時管理之服務實行時的處理，係預設為概括承認。在採用個別承認的場合，在認證處理中，發生有得到所謂有關一部分的API的使用進行許可之最終結果的場合。亦即，就有關應用利用者不給予許可承認之API予以禁止使用。
例如，有關圖17的步驟S406的許可鑰的認證，得到有一部分的API為“承認”，一部分的API為“不承認”。這樣的場合，就“承認”的API，成為所謂許可之賦予限制的認證OK。
該場合，例如在實際工時管理處理中，僅就已為使用 OK之API的使用資訊或會計資訊予以更新者方為適切。
而且，服務應用的處理功能，係以存在有無法使用的API的方式，考慮到一部分做限制。
<5．服務實行時之處理例II>
參閱圖20~圖23，說明服務實行時的處理例II。處理例II的場合之基本的處理係與上述之(P1)~(P4)同樣，但此例係於登錄資訊加上複製限制次數或終端識別資訊，於服務實行時也進行這些的確認這一點是相異的。
把該場合的登錄資訊之例表示於圖20。與圖4相異的是，對應到各許可鑰LC#A、LC#B而登錄複製限制次數CN，而且登錄1個或是複數個終端識別資訊DV(DV1、DV2...)這一點。
這些的登錄，係可以以上述的登錄處理過程來進行，也可以作為獨立的終端登錄來進行。而且，例如服務應用亦可在利用者裝置4中初次被啟動時來進行。以下，以於初次啟動時進行登錄之例進行說明。
圖21係與先前的圖16同樣，主要表示利用者裝置4與API伺服器20的處理。與圖16同一之處理係賦予同一之步驟編號並省略說明。相異的是，在利用者裝置4中，加上步驟S320的服務應用啟動時的處理、與步驟S330；更進一步為步驟S321的發送內容。在API伺服器20側，步驟S400的認證處理為相異。而且，對應到步驟S320，進行登錄伺服器10的步驟S180的登錄要求對 應處理。
首先、把利用者裝置4的步驟S320的服務應 用啟動時的處理、與對應於此之登錄伺服器10的處理，以圖22進行說明。
在圖22的步驟S3201，於利用者裝置4，進行服務應用啟動。根據服務應用進行處理之利用者裝置4，係判斷此次的啟動是否在作為該利用者裝置4之終端上為初次，不為初次啟動的話，從步驟S3202剔除處理。該場合，結束圖21的步驟S320。
僅初次啟動的場合，從步驟S3202前進到S3203。在步驟S3203，利用者裝置4係取得自己的終端識別資訊。終端識別資訊乃是可以識別終端本身之資訊。例如，預設有MAC位址(Media Access Control address，媒體存取控制位址)或作為資訊處理裝置之製品序號等。
接著，利用者裝置4係在步驟S3204對登錄伺服器10發送終端登錄要求。此時，與終端登錄要求一塊，也發送服務代碼、許可鑰、及終端識別資訊。
尚且，該終端登錄要求，係可以使用利用者WEB13來實行，也可以是不透過網站利用者裝置4發送到EC管理系統1之形態。
對應到終端登錄要求，在登錄伺服器10，登錄管理部11為例如利用許可處理部11b的功能進行步驟S160之判定可否終端登錄。
該場合，例如經由服務代碼存取登錄資料庫30把登 錄資訊讀出。接著，例如確認以下等：
．是否登錄著服務代碼。
．許可鑰是否對應著服務代碼。
．就許可鑰，許可承認資訊是否為“承諾”。
．就該許可鑰，已經登錄著的終端識別資訊DV的數目，是否尚未達到複製限制次數CN的數目。
．發送完畢的終端識別資訊，是否已經作為終端識別資訊DV沒有登錄完畢。
．發送完畢的終端識別資訊，是否為登錄禁止對象(例如登載黑名單)。
接著，於這些條件清除完畢的場合判定成可登錄。
為可登錄的場合，登錄伺服器10係從步驟S161前進到S162，就終端登錄要求進行使發送完畢的終端識別資訊，對應到許可鑰登錄到登錄資料庫30之處理。
接著，登錄伺服器10在步驟SI63進行登錄確認處理。此乃是對應用利用者，用以求取有關終端登錄的確認之處理。
在登錄確認處理，至少對應用利用者進行終端識別資訊登錄的通知(終端登錄通知)。該通知，係對以對應到許可鑰而登錄中的利用者特定資訊所示之應用利用者來進行。從而，實際上也有乃是發送完畢的終端登錄要求之利用者裝置4的場合，也有成為其他的利用者裝置4的場合。通知係可以作為電子郵件，發送到例如從利用者特定 資訊所導入的電子郵件位址，也可以是其他的手法。該步驟S163，係終歸倒底，成為所謂對經由利用者特定資訊所被登錄之應用利用者進行通知之處理。
經由該通知，正規的應用利用者可以知道，某利用者裝置4的終端識別資訊已被登錄了。此為應用利用者本身所使用的終端，為管理下的終端的話是沒有問題。可是，對應用利用者來說為未知的終端的話，是有服務應用與許可鑰被不正當複製或是盗用而流出的可能性。應用利用者，係如此經由通知可以知道未授權使用的危險性。
作為步驟S163的登錄確認處理，係至少進行以上的終端登錄通知；更進一步亦可進行以下的處理。
例如，可以對終端登錄通知，把來自應用利用者的終端登錄承諾的通知予以待機，僅在得到了終端登錄承諾的通知之場合，把在步驟S162登錄過的終端識別資訊予以有效化。亦即，為根據正當的應用利用者的管理之服務應用的啟動的話，於應用利用者求取承諾通知，藉由該承諾通知擔保終端識別資訊的登錄的正當性。
另一方面，亦可於指定期間內沒有得到承諾通知，或者是從應用利用者發送拒絕通知完畢的場合，於刪除了已登錄之終端識別資訊DV之下，與在步驟S161作為不可登錄的場合同樣，前進到步驟S165。
而且，在拒絕通知的場合，也考慮到把該對象的終端識別資訊登錄到上述的黑名單。
繼續，登錄伺服器10係在步驟S164，對利用 者裝置4進行登錄完畢通知。所謂該場合的通知端之利用者裝置4，乃是在步驟S3204發送終端登錄要求完畢之終端。亦即，成為對終端登錄要求之結果通知。
另一方面，在不可登錄的場合，登錄伺服器10係從步驟S161前進到S165，對利用者裝置4進行不可登錄通知。
在利用者裝置4，以步驟S3205確認登錄完畢通知或是不可登錄通知、並記憶這個。
以上之圖22的處理，係以圖21的步驟S320、S180來進行。
在利用者裝置4，步驟S320之啟動處理之後，在步驟S330，確認記憶有登錄通知。亦即，初次啟動時，於稍早接收有登錄完畢通知抑或是不可登錄通知的緣故，並對其予以確認。第2次以後之啟動時，係於初次啟動時以上述圖22的處理被通知，確認已記憶之登錄完畢通知抑或是不可登錄通知。
於步驟S330中，在通知內容為不可登錄通知的場合，該利用者裝置4乃是尚未登錄有終端識別資訊DV之終端。該場合，所謂正規的服務應用使用尚未被承認的緣故，前進到步驟S324，成為錯誤結束。
在登錄完畢通知已被確認的場合，從步驟S330前進到S321，利用者裝置4對API伺服器20發送API使用要求。於該API使用要求之際，利用者裝置4發送服務代碼與許可鑰，更進一步同時發送終端識別資訊。 尚且，於API使用要求，也包含顯示進行過要求的服務應用之服務識別資訊、及指定成為使用要求的對象的API之資訊。
在利用者裝置4側，該之後的步驟S322，S323，S324，係進行與處理例I的圖16同樣的處理。
在API伺服器20，對API使用要求，與圖16的場合同樣，實行步驟S400~S404的處理，但是在步驟S400的認證處理有相異點的緣故，以圖23說明之。
圖23表示API伺服器20藉由認證部21所實行的認證處理。
認證部21係在步驟S410A，與API使用要求一起取得從利用者裝置4所發送完畢的服務代碼與許可鑰，更進一步取得終端識別資訊。
而且，認證部21，也取得表示作為API使用要求的資訊所包含之服務識別資訊與使用要求對象的API之資訊。
接著，認證部21係在步驟S411，使用服務代碼與許可鑰存取到登錄資料庫30，取得對應到該服務代碼及許可鑰之登錄資訊。該場合，取得於圖20所示之登錄資訊。亦即，作為對應到服務代碼的登錄資訊，取得服務識別資訊、應用提供者的資訊、及API使用資訊。而且作為對應到許可鑰之登錄資訊，取得對應到該許可鑰本身之利用者特定資訊、許可承認資訊、及終端識別資訊。例如，許可鑰LC#A的場合，為有關利用者特定資訊MC-A、及 許可鑰LC#A之許可承認資訊、終端識別資訊DV1，DV2，DV3。
之後的步驟S412~S419係與以圖17所已說明之處理同樣的緣故，省略重複說明。
在該圖23之例，作為步驟S420，認證事項加上有終端識別資訊。
在步驟S420，認證部21作為有關終端識別資訊的認證，例如進行以下的確認。
．確認是否為已正規登錄之終端識別資訊
確認與API使用要求一起發送完畢之終端識別資訊，是否與被登錄資料庫30所已登錄的終端識別資訊DV一致。該場合，以與許可鑰之對應關係進行一致確認。例如，以圖20的場合進行說明的話，在API使用要求中從利用者裝置4發送許可鑰LC#A完畢的場合，認證部21確認從利用者裝置4發送完畢的終端識別資訊，是否與對應到許可鑰LC#A之任一終端識別資訊DV1、DV2、DV3一致。
在加上有關這樣的終端識別資訊的認證之下，進行步驟S417、S418的認證結果判定，圖21的步驟S400的認證處理完畢。
接著之後，在API伺服器20，實行步驟S401~S404的處理，與圖16的場合同樣。
如以上的處理例II般，以進行使用了複製限制次數或終端識別資訊之判斷的方式，可以更提高服務應 用利用的安全性。亦即，API伺服器20可以以作為利用者裝置4的終端單位做認證，在使用尚未被登錄的終端的場合，作為有未授權使用的可能性，可以拒絕API使用要求。例如，可以禁止因為服務應用之不正當複製或許可鑰的盗用，被啟動了服務應用的場合之API使用。
而且，於終端識別資訊DV之登錄的條件，就許可鑰，以已經登錄的終端識別資訊DV的數目不超過複製限制次數CN為條件的方式，也可以防止服務應用的複製氾濫。
尚且，複製限制次數CN的資訊，亦可並非得要對應到許可鑰而登錄。例如，在全部的場合，複製限制次數係以“對1個許可鑰為3次”等在系統上做設定之場合，是沒有登錄複製限制次數CN之必要。
而且，複製限制次數亦可對應到服務應用(服務識別資訊)而登錄。例如，應用提供者於上述之API使用登錄要求中，可以輸入複製限制次數。對應於此，登錄伺服器10在圖6之步驟S103的時點，使複製限制次數CN對應到服務識別資訊或服務代碼而登錄。
而且，複製限制次數CN，係可以應用提供者對有關預先自己所提供的服務應用設定成固定的，通知到登錄伺服器10。該場合，也考慮到固定值的複製限制次數CN對應到服務代碼而被自動登錄。
而且，使複製限制次數CN對應到許可鑰的場合，應用提供者可以對每一顧客(應用利用者)設定複製 限制次數CN。
例如，作為許可發行要求把利用者特定資訊發送到登錄伺服器10之際，對應到該利用者特定資訊而可以設定複製限制次數CN。在登錄伺服器10，以圖7的步驟S113的處理，對應到許可鑰、利用者特定資訊而登錄複製限制次數CN。
如此的話，應用提供者可以對個別應用利用者設定服務應用的許容複製次數。例如，可以經由服務應用提供的契約內容等，設定許容複製次數。
而且，服務利用者可以設定複製限制次數CN。
例如，作為複製限制次數CN的上限，在系統上、或者是經由應用提供者的設定所決定的範圍內，在應用利用者進行許可承認之際，可以輸入複製限制次數CN。接著，登錄伺服器10係於圖8的步驟S124的許可承認資訊的登錄之際等，對應到該許可鑰登錄複製限制次數CN。該場合，在所謂應用利用者嚴防自己的資訊(營業資訊M1dt等)的流出之目的下，在所謂欲限制服務應用的複製時是有用的。
而且，複製限制次數CN亦可不被登錄。例如，在不進行複製次數限制的場合是沒有必要。或者是，在應用提供者對有關自己所提供的服務應用不想設置複製次數限制的場合，也考慮到有關該應用提供者的服務應用不去登錄複製限制次數CN之手法。
而且，也考慮到登錄複製限制次數CN，但不登錄終端識別資訊DV之例。
<6．服務實行時之處理例III>
參閱圖24說明服務實行時的處理例III。基本的處理係與上述之(P1)~(P4)同樣；此例係在對API使用要求之認證之際，進行對應用提供者之確認。
於圖24，加到利用者裝置4與API伺服器20的處理，也揭示有提供者裝置3A的處理。在利用者裝置4與API伺服器20的處理中，與圖16同樣的處理，係賦予同一之步驟編號省略說明。該場合，於API伺服器20，進行步驟S460之真正應用確認處理這一點與圖16相異。
API伺服器20係從利用者裝置4發送API使用要求，例如在進行過步驟S400的認證後，作為步驟S460之真正應用確認處理，對提供者裝置3A進行確認要求的通知。
該場合，把表示例如服務代碼、許可鑰、服務識別資訊、利用者特定資訊等，將要被實行的服務應用的內容或權限之資訊，發送到提供者裝置3A。
關於提供者裝置3A，在步驟S351，進行例如確認該服務應用的內容或權限是否為正當之對照處理，把該結果作為確認回應通知到API伺服器20。
API伺服器20係確認回應為OK的話，提供者確認OK、確認回應為NG的話作為提供者回應NG進行處理。
接著API伺服器20，係在步驟S401A對利用者裝置4通知認證結果與提供者確認結果。
變成認證NG或是不能認證的場合，或者是變成提供者確認NG的場合，API伺服器20從步驟S402A前進到S405，作為API使用禁止，結束對API使用要求之處理。
而且，在利用者裝置4，在接收了認證NG或是不能認證的通知、或者是提供者確認NG的通知的場合，從步驟S322A前進到S324，服務應用變成錯誤結束。
API伺服器20係變成認證OK而且提供者確認OK的場合，從步驟S402A前進到S403之實際工時管理處理、及步驟S404的API處理。
在利用者裝置4，在得到了認證OK而且提供者確認OK的通知的場合，從步驟S322A前進到S323，實行服務應用的通常處理。
如此，以於服務實行時對服務應用是否為真正者取得提供者裝置3A側的確認之方式，可以排除不正當應用所致之API使用。
具體方面，有關某服務應用，考慮到已被登錄的服務代碼被盗用，被附加到尚未被正規登錄之其他的服務應用而使用的場合。
例如預設有：惡意的應用利用者取得不當附加了服務代碼之服務應用，使用自己發行的許可鑰存取API伺服器20的場合，或更進一步許可鑰本身也被盗用，第三者使 用不正當服務應用的場合等。
有這樣的不正當服務應用所致之API使用要求的場合，以把該服務應用的內容確認在應用提供者側的方式，可以排除未授權使用。
尚且，為了在應用提供者側(提供者裝置3A)進行確認，例如考慮到進行服務識別資訊的對照。作為服務識別資訊，於1個的服務應用的標題包含固有的資訊的話，可以確認服務代碼與服務應用的關係。
而且，真正應用確認處理係僅進行對提供者裝置3A的通知，不進行受理確認回應。經由確認回應的待機，是為了避免服務實行的效能下降。也僅對提供者裝置3A通知，以應用提供者進行確認而應對的方式，可以於事後對應到不正當應用使用。
而且，真正應用確認處理，係作為其中一例，在步驟S400的認證後進行，但也可以在步驟S400的認證處理之前進行。
而且，不是在每次進行API使用要求之際，例如，可以僅在服務應用之初次的API使用要求之際進行真正應用確認處理，或者是定期的進行。
而且，也可以把以上的處理例III，適用到處理例II的場合。
<7．服務實行時之處理例IV>
作為服務實行時的處理例IV，說明有關利用圖1的 提供者裝置3B之ASP的場合。
尚且，作為ASP之提供者裝置3B的場合，不是利用者裝置4而是以提供者裝置3B啟動服務應用，提供者裝置3B依照服務應用進行API使用。該場合，基本的上可以考慮到上述的處理例I、II、III之利用者裝置4的處理被實行在提供者裝置3B中。
但是，作為該處理例IV，係說明也加上了排除惡意的ASP所致之API使用之處理之例。
圖25為示意性的表示有關服務實行時的認證或API使用的處理之關連部位與資訊的交換。
該場合，在提供者裝置3B側準備服務應用準備。提供者裝置3B係對應來自利用者裝置4的請求，實行服務應用。亦即，於提供者裝置3B啟動服務應用。於此之際，服務應用係使用API伺服器20所準備的API，進行必要的資訊存取。例如，對應到來自應用利用者M1的利用者裝置4的請求，在提供者裝置3B被啟動著的服務應用，係使用API#1對營業資訊M1dt進行存取。接著，把例如商品管理、庫存管理、顧客管理等的服務的結果提供到利用者裝置4。經由此形態，應用利用者可以享受服務應用的服務。
服務實行時的處理係大致上以接下來的(P11)~(P14)的順序進行。
(P11)提供者裝置3B接收來自利用者裝置4的服務要求及許可鑰。接著提供者裝置3B係根據已啟動之服務 應用，對API伺服器20發送API使用要求。於該場合也發送服務代碼與許可鑰。
(P12)API伺服器20，係利用認證部21的功能，根據隨API使用要求的服務代碼與許可鑰進行認證處理。接著，把認證結果通知到提供者裝置3B。此時，作為真正使用確認處理，在API伺服器20與利用者裝置4之間進行確認要求與確認回應的交換。API伺服器20也把該確認結果通知到提供者裝置3B。
(P13)認證OK的場合，API伺服器20係利用實際工時管理部22的功能，根據服務代碼與許可鑰，就應用提供者與應用利用者，進行個別的實際工時管理處理。
(P14)認證OK的場合，API伺服器20許可API使用。亦即，因應在服務應用所致的處理過程所發生的要求，實行API使用。
以下，參閱圖26說明服務實行時之各部分支具體的處理例。
圖26表示利用者裝置4、提供者裝置3B、API伺服器20的處理。尚且、所謂在圖26之API伺服器20的處理，係包含：使用認證部21以圖3所說明之認證處理部21a、登錄資訊取得部21b的功能而實行的處理、與實際工時管理部22的功能所致之處理、與API24所致之處理。
應用利用者享受作為ASP的應用提供者所提供的服務之場合，對應用提供者委託服務實行。亦即，利 用者裝置4係在步驟S350，對提供者裝置3B發送服務實行要求。此時，也發送於該服務所取得的許可鑰。
在提供者裝置3B，因應服務實行要求，在步驟S500進行服務應用的啟動處理。
以啟動服務應用的方式，藉由該服務應用作為所被規定的處理，在提供者裝置3B進行步驟S501之後的處理。
在步驟S501，提供者裝置3B對API伺服器20發送API使用要求。
於此API使用要求之際，提供者裝置3B，也同時發送附加到服務應用之服務代碼、與從利用者裝置4接收的許可鑰。
尚且，於API使用要求，也包含顯示進行過要求的服務應用之服務識別資訊、及指定成為使用要求的對象的API之資訊。
API伺服器20係因應API使用要求在步驟S400，利用認證部21的功能，進行例如在圖17或圖23之已說明的認證處理。
於認證處理繼續，API伺服器20係在步驟S450進行真正使用確認處理。
該場合，API伺服器20係在對應到許可鑰而被登錄著的利用者特定資訊所示之利用者裝置4，發送確認要求。例如，根據許可鑰、服務識別資訊、利用者特定資訊等，把表示將要實行的服務應用的內容或權限之資訊，發送到利用者裝置4。
關於利用者裝置4，在步驟S351，進行例如確認該服務應用的內容或權限是否為正當之對照處理，把該結果作為確認回應通知到API伺服器20。
API伺服器20係確認回應為OK的話，利用者確認OK、確認回應為NG的話作為利用者回應NG進行處理。
接著API伺服器20，係在步驟S401B對提供者裝置3B通知認證結果與利用者確認結果。
變成認證NG或是不能認證的場合，或者是變 成利用者確認NG的場合，API伺服器20從步驟S402A前進到S405，作為API使用禁止，結束對API使用要求之處理。
而且，在提供者裝置3B，在接收了認證NG或是不能認證的通知、或者是利用者確認NG的通知的場合，從步驟S502前進到S504，服務應用變成錯誤結束。
API伺服器20係變成認證OK而且利用者確認OK的場合，從步驟S402A前進到S403之實際工時管理處理、及步驟S404的API處理。
在提供者裝置3B，在得到了認證OK而且利用者確認OK的通知的場合，從步驟S502前進到S503，實行隨API使用之服務應用的通常處理。接著，把作為服務結果所得的服務資料發送到利用者裝置4。在利用者裝置4以步驟S352接收服務資料。應用利用者享受服務。
如以上般，也在作為ASP之提供者裝置3B實行服務應用的場合，與處理例I的場合同樣進行認證或 實際工時管理，可以確保資訊的安全性或進行應用提供者、應用利用者之個別的實際工時管理。
而且，在此處理例IV，於服務實行時，對服務應用是否藉由提供者裝置3B正確地使用這一點進行利用者裝置4側的確認。經此，可以排除惡意的ASP盗用了許可鑰而實行服務應用所致之不正當的API使用。
具體方面，防止盗用了某應用利用者已承認之許可鑰之應用提供者，用了該許可鑰而實行服務應用，進行應用利用者的資訊(營業資訊M1dt等)之不正當閱覧、流出、竄改等。
尚且，作為應用利用者側的確認，係可以確認是否因應正規地發了服務實行要求之服務應用的實行。從而，也可以例如在利用者裝置4側不等待使用者的操作而自動地把確認回應發送到API伺服器20。
而且，真正使用確認處理係僅進行對利用者裝置4的通知，不進行受理確認回應。經由確認回應的待機，是為了避免服務實行的效能下降。也僅對利用者裝置4的通知，以應用利用者進行確認而應對的方式，可以於事後知道許可鑰不正當流出，可以對應到服務應用之未授權使用。
而且，真正使用確認處理，係作為其中一例，在步驟S400的認證後進行，但也可以在步驟S400的認證處理之前進行。
而且，不是在每次進行API使用要求之際，例如，可 以僅在服務應用之初次的API使用要求之際進行真正應用確認處理，或者是定期的進行。
<8．EC管理系統的實施之效果>
以上，說明完畢EC管理系統1的登錄伺服器10或API伺服器20所致之動作，根據該實施方式的話得到以下的效果。
首先，作為EC管理系統1之資訊處理裝置，係具備服務代碼處理部11a、持有作為許可處理部11b之功能之登錄伺服器10。
服務代碼處理部11a係對從提供者裝置3所發送完畢之API使用登錄要求，生成表示該服務(服務應用)作為API使用服務而已被登錄之服務代碼。接著，進行使服務識別資訊及API使用資訊與服務代碼對應進行登錄之處理。
許可處理部11b，係對應到從提供者裝置3已發送完畢之有關服務的利用者特定資訊，使用了在API使用資訊所示之API之資訊存取權限生成未承認狀態的許可資訊。而且，受理從藉由對應到許可資訊之利用者特定資訊所示之應用利用者的利用者裝置4之、表示資訊存取權限的承認或是不承認之許可承認資訊。接著，使許可承認資訊對應到許可資訊進行登錄。
以經由作為這樣的登錄伺服器10之構成進行登錄處理的方式，有關隨API使用之服務應用，利用服務代碼明 示正規登錄，而且利用許可資訊特定應用利用者，而且應用利用者可以以給予許可承認的形式進行管理。
從而EC管理系統1為利用服務代碼可以管理應用提供者，而且利用許可資訊可以得到可以管理應用利用者的狀態之登錄資訊。
而且，許可資訊係作為應用利用者就有關服務在已辨識之下可以承諾服務實行之形式。從而，提供有關隨應用利用者所致之API使用之服務利用之主體性的可否判斷機會。
而且，特別是，以本實施方式為前提之系統，係構成為：使用API之服務應用，是藉由複數位、1位或是複數位應用提供者而提供，複數位應用利用者之每一位可以享受可以被自己利用之服務應用的實行所致之服務。亦即，在存在複數個服務應用、與複數位應用利用者中，實現用以適切的管理或正當的API使用之登錄，在系統管理上，非常有用。
而且，登錄伺服器10，係進行對應用利用者之許可資訊發行的通知處理。接著，此時，進行對應到許可資訊之服務的資訊與風險資訊的提示處理。經此、應用利用者正確理解到服務應用的內容或風險，可以進行許可承認。
作為所提示之風險資訊，使用API使用資訊。以把API使用資訊包含道風險資訊的方式，應用利用者藉由服務可以具體地辨識被利用到哪樣的資訊，對於應用利用者 所致之主體性的許可承認這些也是適切的。
而且，登錄伺服器10，係把對作為風險資訊 已通知之1個或是複數個API使用資訊之、僅來自利用者裝置4之概括承認的資訊，作為許可承認資訊來受理的話，應用提供者可以確保讓本來預設的API使用在全部已維持的狀態下之服務提供。亦即，可以打造在經常性把服務維持在本來的功能的狀態下所提供的環境。
在另一方面，把個別承認的資訊，作為許可承認資訊而受理的話，附加了應用利用者所致之客製化(功能限制)之服務提供可以打造可以的環境。而且，經此，可以詳細反映對服務所致之資訊存取之應用利用者的限制意思。
而且，如服務實行時的處理例II中所述般，登錄伺服器10對應到許可資訊登錄複製允許次數。經此，可以形成服務應用之用以防止無限制擴散之環境。
而且，登錄伺服器10，係對應到許可資訊登錄終端識別資訊。經此，可以提供經由已登錄之終端進行應用利用之環境。藉由應用利用者，成為可以防止來自詐騙或許可盗用等所致之其他終端的服務利用的環境。
而且，有關終端識別資訊，係作為可登錄僅有關所對應之許可資訊的複製允許次數份，進行終端識別資訊的登錄處理。經此，服務應用的複製次數可以實現經由終端識別資訊的登錄可以管理的環境。
而且，於服務實行時的處理例II中所述般，登錄伺 服器10，登錄了終端識別資訊之際，進行登錄的事實通知到應用利用者之處理。經此，應用利用者可以查核自分所已承認之許可資訊所致之服務是否被未授權使用在其他終端，可以提高服務利用的安全性或資訊流出防止效果。
而且，登錄伺服器10，係經由提供者 WEB12，對應到受理API使用登錄要求進行服務代碼的生成處理。而且，藉由提供者WEB12受理許可發行要求。 經此，可以容易化應用提供者所致之用以服務代碼發行的手續或用以許可發行的手續。
而且，登錄伺服器10，係經由利用者WEB13從利用者裝置4受理許可承認資訊，進行對應到許可資訊而登錄之處理。經此，可以容易化應用利用者所致之用以許可承認的手續。
而且，API伺服器20所提供的API，乃是對 營業資訊M1dt等的公開限制資訊可以讀出或是寫入存取之資訊存取用API。該場合，有關使用是為利用者固有資訊之營業資訊M1dt等的服務，可以確保服務應用之API使用，亦即有關資訊存取之資訊安全性。
所謂公開限制資訊，係例如有關應用利用者的營業之資訊，或作成EC管理系統1提供到特定的應用利用者之資訊，例如考慮到在電子商務的日誌資訊、統計資訊、會計資訊等。
但是，本例的系統之API，並沒有限定為對公開限制資訊存取之API。於利用用以對公開資訊存取的API之服 務，適用實施方式的處理是有用的。例如，排除搭他人服務的便車等，用以確保有關服務實行的安全性。亦即，即便是公開資訊，有關該存取，在應用利用者有必要進行許可承認的狀況下，實施方式的系統是有用的。
而且，作為EC管理系統1的資訊處理裝置， 係具備持有作為認證處理部21a、登錄資訊取得部21b的功能之認證部21。認證部21，係可以在API伺服器20內，也可以以API伺服器20的外部的資訊處理裝置來構成。
登錄資訊取得部21b，係在使用API之服務應用中，取得服務識別資訊、與API使用資訊、與服務代碼、與利用者特定資訊、與許可資訊、與許可承認資訊相關聯之登錄資訊。
認證處理部21a，係有了隨服務應用的實行之API使用要求之際，根據服務代碼與許可資訊參閱登錄資訊，進行至少包含服務代碼、API使用資訊、及許可承認資訊的確認之認證處理，許可因應認證結果所已被要求之API使用。
以具有這樣的認證部的方式，在正規的服務應用的使用範圍內，而且在應用利用者之許可承認的範圍內，確保API使用所進行狀態。為此服務的API使用變成在應用利用者的預設範圍內，維持經由API所被存取的資訊的安全性。
特別是，認證，係經由使用被服務代碼及服務代碼所 附帶的API使用資訊之認證，確認作為應用提供者的正當性及使用API的範圍的權限。而且，經由根據許可資訊的認證，確認與應用提供者的關係之應用利用者的正當性、與作為應用利用者的承諾的範圍之API使用。為此、在應用提供者與應用利用者之2者的意思所致的合意範圍內，確保服務應用所致之正當的API使用。
特別是，在存在複數個服務應用與複數位應用利用者中，以進行適切的認證的方式，維持正當的API使用，在系統營運上，非常有用。
尚且，經由應用利用者設定許可承認資訊的 方式，API使用所致之資訊流出的可能性，係也有所謂限制許可承認範圍之側面。假設，通常係即便是因為無法預設想般的行為或駭侵等而進行不正當API使用，所導致之資訊流出範圍被止限於應用利用者所當初承認的範圍。從而，藉由應用利用者，在預設了這樣的最壞的事態之下，也可以進行許可承認。
而且，藉由認證部21，接收從實行了服務應 用之外部終端裝置連同API使用要求一起發送之服務代碼及許可資訊，進行認證處理。亦即，使用同時發送API使用要求並附帶服務代碼或許可資訊之登錄資訊，進行認證。經此，有關服務應用的正當性、及許可鑰所帶來的應用利用者的正當性，可以適切地認證。
而且，在對全部之認證處理，服務代碼、服務識別資訊、API使用資訊、及許可承認資訊可以進行指定的確認 的場合，許可有關API使用要求之API使用。經此，可以實現最優先確保資訊的安全性之運用。
而且，作成於登錄資訊包含對應到許可資訊之終端識別資訊，於認證處理中，就發送API使用要求完畢的外部終端裝置，進行使用了終端識別資訊之認證。經此，成為可以對應到應用程式或許可鑰之不正當複製、不正流出之認證。
而且，如處理例IV般，對API使用要求，進行對藉由對應到許可資訊之利用者特定資訊所示的應用利用者之API使用要求發生的通知處理。經此，應用利用者可以辨識所實行的應用程式，可以給予是否為正規的服務利用之判斷機會。經此，發現許可鑰盗用等的不正當利用的話，可以進行應對。
特別是，以API伺服器20等待確認回應而許可API使用的方式，可以迴避不正當的服務利用。
而且，如處理例III般，對API使用要求，以進行對應用提供者之API使用要求發生的通知處理的方式，應用提供者可以辨識所實行的應用程式，可以給予是否為正規的服務利用之判斷機會。經此，發現服務應用或服務代碼之不正當複製或盗用的話，可以進行必要的應對。
特別是，以API伺服器20等待確認回應而許可API使用的方式，可以迴避根據服務代碼或服務代碼的擴散之不正當的服務利用。
而且，作為EC管理系統1之資訊處理裝置， 係具備實際工時管理部22。實際工時管理部22，係可以在API伺服器20內，也可以以API伺服器20的外部的資訊處理裝置來構成。
實際工時管理部22，係在經由認證許可了API使用之場合，根據API使用要求之服務代碼，生成應用提供者的實際工時資訊，而且根據許可資訊，生成應用利用者的實際工時資訊。
在本實施方式的系統，就隨API使用之服務應用的實行，進行使用了服務代碼與許可資訊之認證，經由服務代碼可以做應用提供者的實際工時管理，經由許可資訊可以做應用利用者的實際工時管理。亦即，有關API使用，可以適切地管理應用提供者與應用利用者之各個的實際工時。
而且，於認證OK的場合進行實際工時管理。經此，實際上，作為API使用所進行的場合之實際工時，可以為應用提供者、應用利用者的實際工時管理。
特別是，在存在複數之多樣的服務應用、與複數位應用利用者中，就各個的服務應用與應用利用者實現正當的實際工時管理，在系統營運上，非常有用。
而且，實際工時管理部22，係根據API使用要求之服務代碼，生成對應用提供者之會計資訊。而且，根據API使用要求之許可資訊，生成對應用利用者之會計資訊。
亦即，就各個應用提供者、應用利用者，實現對應到 實際的API使用之會計管理，也可以個別會計對應用提供者、應用利用者之API使用費用。
<9．程式及記憶媒體>
以上，說明完畢了作為本發明的資訊處理裝置的實施方式之EC管理系統1，但實施方式的程式，乃是於資訊處理裝置(CPU等)實行EC管理系統1之登錄伺服器10或API伺服器20(認證部21、實際工時管理部22)的處理之程式。
實施方式的程式，係對從提供者裝置3所發送完畢之有關用了使用API的應用程式之服務的API使用登錄要求，該服務生成表示作為API使用服務已被登錄之服務代碼，同時資訊處理裝置實行使服務的服務識別資訊、及API使用資訊與服務代碼對應並予以登錄之處理。而且，對應到從提供者裝置3已發送完畢之有關服務的利用者特定資訊，資訊處理裝置實行使用了在API使用資訊所示之API之資訊存取權限生成未承認狀態的許可資訊的處理。更進一步，受理從藉由對應到許可資訊之利用者特定資訊所示之應用利用者的利用者裝置4之、表示資訊存取權限的承認或是不承認之許可承認資訊，資訊處理裝置實行對應到許可資訊而登錄的處理。
亦即，此程式，乃是對登錄伺服器10實行以圖6~圖9所說明之處理的程式。而且，於登錄伺服器10，也有實行圖21的步驟S180之場合。
而且，實施方式的程式，係資訊處理裝置實 行取得有關用了使用API的應用程式之服務所致之API使用要求之服務代碼與許可資訊之處理。而且，對登錄資訊，其關連了從有關服務的提供者裝置3所已被指定之服務識別資訊及API使用資訊、與表示有該服務作為API使用服務而已被登錄之服務代碼、與對應到特定從提供者裝置3所被指定之應用利用者之利用者特定資訊所已發行之許可資訊、與表示使用了來自藉由對應到許可資訊之利用者特定資訊所示之應用利用者的利用者裝置4之在API使用資訊所示之API之資訊存取權限之承認或是不承認之許可承認資訊，資訊處理裝置實行根據有關API使用要求之服務代碼與許可資訊進行存取之處理。更進一步，參閱以該存取所取得之登錄資訊，進行至少包含服務代碼、API使用資訊、及許可承認資訊的對照之認證處理，資訊處理裝置實行許可因應認證結果所要求之API使用的處理。
亦即，該程式，乃是對作為具有認證部21之API伺服器20的資訊處理裝置，實行在圖16、圖21、圖24或是圖26所說明的處理、及在圖17或是圖23所說明的處理之程式。
而且，實施方式的程式，係更進一步於許可 了API使用之場合，根據API使用要求之服務代碼，生成應用提供者的實際工時資訊，而且根據許可資訊，資訊處理裝置實行生成應用利用者的實際工時資訊之處理。
亦即，該程式，乃是對作為具有實際工時管理部22 之API伺服器20的資訊處理裝置，實行在圖16、圖21、圖24或是圖26所說明的處理、特別是在圖18所說明的處理之程式。
利用這樣的程式，可以實現作為上述之EC管理系統1的資訊處理裝置。
接著，這樣的程式係可以預先紀錄在作為內藏在電腦裝置等的機器之記錄媒體之HDD、或具有CPU之微電腦內的ROM等。或者是，而且於半導體記憶體、記憶卡、光碟、光磁性碟片、磁性碟片等之可移除式記錄媒體，可以暫時的或是永續的儲存(記錄)。而且，這樣的可移除式記錄媒體，作為所謂套裝軟體而可以提供。
而且，這樣的程式，係除了從可移除式記錄媒體安裝到個人電腦等之外，也可以從下載網站，透過LAN、網際網路等的網路進行下載。
<10．變形例>
本發明係不限於上述的實施方式，考慮到各種的變形例。
登錄時的處理或服務實行時的處理，並不限於上述例子。API使用登錄要求、許可承認、API使用要求等之資訊處理裝置間的通訊手法、資訊提示手法、應用提供者或應用利用者所致之輸入手法係多樣地考慮。
例如，作為在圖16、圖21、圖24、圖26所例示之API使用時的處理，啟動了服務應用之利用者裝置4，係 可以同時發送API使用要求與實際的API處理要求。該場合，認證部21進行認證為OK的話，進行API處理。以圖16來說，利用者裝置4係在步驟S321的階段把API使用要求及API處理要求(S323)發送到API伺服器20。API伺服器20為在步驟S400進行過認證後為OK的話，許可API使用進行步驟S404的API處理。認證結果的通知係作為API處理結果，可以在步驟S404的處理內進行。從而，步驟S401、S322變成不要。
而且，同樣，作為這些的API使用時的處理、作為步驟S403所示之實際工時管理處理，係可以在作為步驟S404所示之API處理後進行。實際上，於API處理後，以進行包含了會計處理之實際工時管理的方式，實際工時資料，係反映API處理結果，可以更容易反映本來的實際工時。
而且，有關本發明，係以適用到進行電子商務網路系統之例進行說明，但未必得要被限定在電子商務之服務之API使用。本發明乃是在多樣的服務應用中可以適用在發生API使用之場合的技術。
而且，在其意味下，享受服務之應用利用者，不限於電子商店的營運者等。
順便一說，上述的程式，乃是例如EC管理系統1中實現有關登錄或認證、實際工時管理之功能之程式，但從上述的實施方式，也掌握作為服務應用的程式的發明。亦即，乃是具備以下的構成之程式。
一種程式，乃是具備構成如應用提供者把使用提供預先準備好的API應用程式提供給應用利用者、前述應用利用者可以享受已被提供的應用程式的實行所帶來的服務般之系統的資訊處理裝置實行處理之前述應用程式，係把：取得表示該應用程式所附帶之作為該應用程式API使用服務而已被登錄之服務代碼之處理、取得對應到特定從應用提供者裝置所被指定的應用利用者之利用者特定資訊而已被發行之許可資訊之處理、以及把用於API使用之API使用要求隨前述服務代碼與前述許可資訊一起發送之處理，用資訊處理裝置來實行。
上述的實施方式之服務應用，成為這樣的程式的實施方式。
而且，作為記憶了這樣的程式之記憶媒體、或也作為利用該程式實行上述各處理之資訊處理裝置，掌握了發明。亦即，利用者裝置4或提供者裝置3B成為這樣的資訊處理裝置之實施方式。
1‧‧‧EC系統
2‧‧‧網路
3A、3B、3C‧‧‧應用提供者裝置
4A、4B、4C‧‧‧應用利用者裝置
SA1、SA2、SA3、SA10、SA20、SA21‧‧‧服務應用

Claims (9)

  1. 一種資訊處理裝置，係具備構成為如下之系統：使用預先被準備好的API之應用程式，是藉由複數位、1位或是複數位應用提供者而提供，複數位應用利用者之每一位可以享受可以被自己利用之應用程式的實行所致之服務；其特徵為具備：登錄資訊取得部，係取得關連了以下之登錄資訊：從有關用了使用API之應用程式的服務之應用提供者裝置所已被指定之服務識別資訊及API使用資訊、與表示有該服務作為API使用服務而已被登錄之服務代碼、與對應到特定從前述應用提供者裝置所被指定之應用利用者之利用者特定資訊所已生成之許可資訊、與表示使用了來自藉由對應到前述許可資訊之利用者特定資訊所示之應用利用者的應用利用者裝置之在前述API使用資訊所示之API之資訊存取權限之承認或是不承認之許可承認資訊；認證處理部，係在有了隨前述應用程式的實行之API使用要求之際，根據有關該API使用要求之服務代碼與許可資訊，參閱經由前述登錄資訊取得部所取得的登錄資訊，進行至少包含以下之認證處理：服務代碼所致之正規登錄的確認、以該API使用要求被要求使用之API與API使用資訊的一致確認、許可資訊的正當性的確認、及許可承認資訊所致之承認確認，因應認證結果許可已被要求之API使用；以及實際工時管理部，係在許可了API使用之場合，根據 API使用要求之服務代碼，生成應用提供者的實際工時資訊，而且根據許可資訊，生成應用利用者的實際工時資訊。
  2. 如請求項1之資訊處理裝置，其中，前述實際工時管理部，係根據API使用要求之服務代碼，生成對應用提供者之會計資訊。
  3. 如請求項1或2之資訊處理裝置，其中，前述實際工時管理部，係根據API使用要求之許可資訊，生成對應用利用者之會計資訊。
  4. 如請求項1至3中任一項之資訊處理裝置，其中，前述認證處理部，係接收從已實行前述應用程式之外部終端裝置連同API使用要求一起發送之前述服務代碼及前述許可資訊，進行認證處理。
  5. 如請求項1至4中任一項之資訊處理裝置，其中，前述認證處理部，係在就全部之服務代碼、服務識別資訊、API使用資訊、許可資訊、及許可承認資訊，可以確認的場合，許可有關API使用要求之API使用。
  6. 如請求項1至5中任一項之資訊處理裝置，其中，於前述登錄資訊包含對應到前述許可資訊之終端識別資訊，前述認證處理部，係在認證處理中，就發送實行了前 述應用程式之API使用要求完畢之外部終端裝置，也進行用了前述終端識別資訊之認證。
  7. 一種資訊處理方法，乃是具備如下之系統之資訊處理裝置之資訊處理方法，該系統構成為：使用預先被準備好的API之應用程式，是藉由複數位、1位或是複數位應用提供者而提供，複數位應用利用者之每一位可以享受可以被自己利用之應用程式的實行所致之服務；其特徵為：取得有關用了使用API的應用程式之服務所致之API使用要求之服務代碼與許可資訊；對登錄資訊，其關連了從有關前述服務的應用提供者裝置所已被指定之服務識別資訊及API使用資訊、與表示有該服務作為API使用服務而已被登錄之服務代碼、與對應到特定從前述應用提供者裝置所被指定之應用利用者之利用者特定資訊所已生成之許可資訊、與表示使用了來自藉由對應到前述許可資訊之利用者特定資訊所示之應用利用者的應用利用者裝置之在前述API使用資訊所示之API之資訊存取權限之承認或是不承認之許可承認資訊，根據有關前述API使用要求之服務代碼與許可資訊進行存取；參閱在前述存取所取得的登錄資訊，進行至少包含以下之認證處理：服務代碼所致之正規登錄的確認、以該API使用要求被要求使用之API與API使用資訊的一致確認、許可資訊的正當性的確認、及許可承認資訊所致之承認確認，因應認證結果許可已被要求之API使用； 在許可了API使用之場合，根據API使用要求之服務代碼，生成應用提供者的實際工時資訊，而且根據許可資訊，生成應用利用者的實際工時資訊。
  8. 一種程式，乃是使具備如下之系統之資訊處理裝置實行處理的程式，該系統構成為：使用預先被準備好的API之應用程式，是藉由複數位、1位或是複數位應用提供者而提供，複數位應用利用者之每一位可以享受可以被自己利用之應用程式的實行所致之服務；該程式使前述資訊處理裝置實行以下處理：取得有關用了使用API的應用程式之服務所致之API使用要求之服務代碼與許可資訊之處理；對登錄資訊，其關連了從有關前述服務的應用提供者裝置所已被指定之服務識別資訊及API使用資訊、與表示有該服務作為API使用服務而已被登錄之服務代碼、與對應到特定從前述應用提供者裝置所被指定之應用利用者之利用者特定資訊所已生成之許可資訊、與表示使用了來自藉由對應到前述許可資訊之利用者特定資訊所示之應用利用者的應用利用者裝置之在前述API使用資訊所示之API之資訊存取權限之承認或是不承認之許可承認資訊，根據有關前述API使用要求之服務代碼與許可資訊進行存取之處理；參閱在前述存取所取得的登錄資訊，進行至少包含以下之認證處理：服務代碼所致之正規登錄的確認、以該API使用要求被要求使用之API與API使用資訊的一致確 認、許可資訊的正當性的確認、及許可承認資訊所致之承認確認，因應認證結果許可已被要求之API使用之處理；在許可了API使用之場合，根據API使用要求之服務代碼，生成應用提供者的實際工時資訊，而且根據許可資訊，生成應用利用者的實際工時資訊之處理。
  9. 一種記憶媒體，係記憶了資訊處理裝置所實行的程式，該程式乃是使具備如下之系統之資訊處理裝置實行處理的程式，該系統構成為：使用預先被準備好的API之應用程式，是藉由複數位、1位或是複數位應用提供者而提供，複數位應用利用者之每一位可以享受可以被自己利用之應用程式的實行所致之服務；該程式使前述資訊處理裝置實行以下處理：取得有關用了使用API的應用程式之服務所致之API使用要求之服務代碼與許可資訊之處理；對登錄資訊，其關連了從有關前述服務的應用提供者裝置所已被指定之服務識別資訊及API使用資訊、與表示有該服務作為API使用服務而已被登錄之服務代碼、與對應到特定從前述應用提供者裝置所被指定之應用利用者之利用者特定資訊所已生成之許可資訊、與表示使用了來自藉由對應到前述許可資訊之利用者特定資訊所示之應用利用者的應用利用者裝置之在前述API使用資訊所示之API之資訊存取權限之承認或是不承認之許可承認資訊，根據有關前述API使用要求之服務代碼與許可資訊進行存取之處理； 參閱在前述存取所取得的登錄資訊，進行至少包含以下之認證處理：服務代碼所致之正規登錄的確認、以該API使用要求被要求使用之API與API使用資訊的一致確認、許可資訊的正當性的確認、及許可承認資訊所致之承認確認，因應認證結果許可已被要求之API使用之處理；在許可了API使用之場合，根據API使用要求之服務代碼，生成應用提供者的實際工時資訊，而且根據許可資訊，生成應用利用者的實際工時資訊之處理。
TW103128807A 2013-08-22 2014-08-21 Information processing device, information processing method, program, memory media TWI518597B (zh)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2013/072454 WO2015025405A1 (ja) 2013-08-22 2013-08-22 情報処理装置、情報処理方法、プログラム、記憶媒体

Publications (2)

Publication Number Publication Date
TW201512992A true TW201512992A (zh) 2015-04-01
TWI518597B TWI518597B (zh) 2016-01-21

Family

ID=50792165

Family Applications (1)

Application Number Title Priority Date Filing Date
TW103128807A TWI518597B (zh) 2013-08-22 2014-08-21 Information processing device, information processing method, program, memory media

Country Status (4)

Country Link
US (1) US20150235039A1 (zh)
JP (1) JP5485485B1 (zh)
TW (1) TWI518597B (zh)
WO (1) WO2015025405A1 (zh)

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10015279B2 (en) 2014-11-13 2018-07-03 Blackberry Limited Application assignment reconciliation and license management
US9600810B2 (en) * 2015-02-26 2017-03-21 Blackberry Limited License management for device management system
US10467071B2 (en) 2017-03-17 2019-11-05 Accenture Global Solutions Limited Extensible key management system for application program interfaces
US10726107B2 (en) 2018-10-08 2020-07-28 Mythical, Inc. Systems and methods for facilitating tokenization of modifiable game assets on a distributed blockchain
US10518178B1 (en) 2018-12-06 2019-12-31 Mythical, Inc. Systems and methods for transfer of rights pertaining to game assets between users of an online gaming platform
US11373174B1 (en) 2019-02-05 2022-06-28 Mythical, Inc. Systems and methods for facilitating transfer of ownership of tokens between users on a decentralized database

Family Cites Families (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5892900A (en) * 1996-08-30 1999-04-06 Intertrust Technologies Corp. Systems and methods for secure transaction management and electronic rights protection
JP2002288416A (ja) * 2001-03-27 2002-10-04 Hitachi Ltd 資産管理方法
JP4682520B2 (ja) * 2004-02-25 2011-05-11 ソニー株式会社 情報処理装置、および情報処理方法、並びにコンピュータ・プログラム
JP4994575B2 (ja) * 2004-03-12 2012-08-08 キヤノン株式会社 ネットワークインターフェース装置及びその制御方法、及び画像形成システム
US20060179058A1 (en) * 2005-02-04 2006-08-10 Charles Bram Methods and systems for licensing computer software
US8726356B2 (en) * 2008-02-28 2014-05-13 Nippon Telegraph And Telephone Corporation Authentication apparatus, authentication method, and authentication program implementing the method
JP5359427B2 (ja) * 2009-03-18 2013-12-04 株式会社リコー ライセンス管理システム、ライセンス管理サーバ、情報処理装置、画像形成装置、ライセンス管理方法、およびライセンス管理プログラム
US9697510B2 (en) * 2009-07-23 2017-07-04 Boku, Inc. Systems and methods to facilitate retail transactions
US20110225074A1 (en) * 2010-03-12 2011-09-15 Microsoft Corporation System and method for providing information as a service via web services
JP5175915B2 (ja) * 2010-10-29 2013-04-03 株式会社東芝 情報処理装置及びプログラム
DE112011103872T5 (de) * 2010-11-23 2013-08-22 International Business Machines Corporation Verfahren, Computer-Programm und System, um die Voraussetzung eines virtuellen Abbild eines Software-Produkts zu verwalten
US20130007849A1 (en) * 2011-05-26 2013-01-03 FonWallet Transaction Soulutions, Inc. Secure consumer authorization and automated consumer services using an intermediary service
US9043886B2 (en) * 2011-09-29 2015-05-26 Oracle International Corporation Relying party platform/framework for access management infrastructures
US8856365B2 (en) * 2012-02-28 2014-10-07 Sap Ag Computer-implemented method, computer system and computer readable medium

Also Published As

Publication number Publication date
US20150235039A1 (en) 2015-08-20
JPWO2015025405A1 (ja) 2017-03-02
TWI518597B (zh) 2016-01-21
WO2015025405A1 (ja) 2015-02-26
JP5485485B1 (ja) 2014-05-07

Similar Documents

Publication Publication Date Title
TWI508006B (zh) Information processing device, information processing method, program, memory media
TWI518597B (zh) Information processing device, information processing method, program, memory media
TWI492085B (zh) 用於根據使用者識別符增強產品功能的方法、設備及電腦儲存媒體
TWI413908B (zh) 用於授證應用程式之彈性授證架構
JP6872106B2 (ja) 画像処理装置、制御システム、及びプログラム
KR20070120125A (ko) 온라인 거래 허가 방법, 시스템 및 장치
JP4533935B2 (ja) ライセンス認証システム及び認証方法
JP2004118327A (ja) コンテンツ使用制御装置及びコンテンツ使用制御方法、並びにコンピュータ・プログラム
US20120173884A1 (en) Method for remotely controlling and monitoring the data produced on desktop on desktop software
CN103366304A (zh) 一种虚拟商品使用权的转让方法、装置和设备
KR101979323B1 (ko) 소프트웨어 저작권 인증 관리 방법
JP3950095B2 (ja) 認証サーバ、認証方法、認証依頼端末及び認証依頼プログラム
JP2005301927A (ja) アプリケーションソフトの利用管理システム
JP2016154027A (ja) 電子書籍管理方法、サーバー装置、コンピュータプログラム
CN102130907B (zh) 开发者电话注册
JP5234503B2 (ja) 電子文書管理システム、閲覧端末装置および電子文書管理プログラム
JP2013109544A (ja) 情報処理装置及びプログラム
WO2021160981A1 (en) Methods and apparatus for controlling access to personal data
JP5338843B2 (ja) サーバ装置及び通信方法
JP4752866B2 (ja) コンテンツ情報送信システム
JP2004046606A (ja) ソフトウェア認証サーバ、その代行システム、ソフトウェア認証代行方法およびそのプログラム
JP5949867B2 (ja) サーバ装置並びに通信方法
JP2002123328A (ja) ソフトウェア貸出システム
JP5664708B2 (ja) サーバ装置並びに通信方法
JP2013127695A (ja) コンテンツ利用システム、コンテンツ利用方法、プログラム