Device Management System
The device management system addresses session establishment challenges by using relay and normal domains for cookie generation, ensuring consistent session management with clients via relay systems or directly, thus preventing cookie discard.
Patent Information
- Application Number
- JP2022149014
- Authority / Receiving Office
- JP · JP
- Patent Type
- Patents
- Current Assignee / Owner
- Filing Date
- 2022-09-20
- Publication Date
- 2026-08-26
- Estimated Expiration
- 2042-09-20
AI Technical Summary
Existing device management systems struggle to establish sessions with clients when accessed via a relay system, leading to cookie discard issues due to domain mismatches.
The system employs a frontend that can access a relay system's domain as the backend domain for clients accessing through a relay system, and a normal domain for direct access, ensuring cookies are generated within valid domains, allowing sessions to be established regardless of relay system usage.
Enables session establishment with clients both through and without relay systems, preventing cookie discard and ensuring seamless communication.
Smart Images

Figure 0007911330000001 
Figure 0007911330000002 
Figure 0007911330000003
Abstract
Description
Technical Field
[0004] ,
[0006] , , , , , ,
[0005] , , , , , ,
[0001] The present invention relates to a device management system for managing devices.
Background Art
[0002] Conventionally, a device management system for managing devices has been known (see, for example, Patent Document 1).
Prior Art Documents
[0007] With this configuration, when the device management system of the present invention receives an API request from a client via the relay system to access a URL where the first domain is a domain name, the front end accesses the relay system's domain as the backend domain, the backend generates a cookie that includes the backend domain accessed by the front end within the range of domains where cookies can be used, and when the backend generates a cookie that includes the relay system's domain within the range of domains where cookies can be used, the front end sends this cookie to the client via the relay system. This prevents the client from discarding the cookie due to the relay system's domain not being included in the range of domains included in the cookie sent to the client via the relay system, and as a result, a session can be established with the client even when accessed via the relay system.
[0008] In the device management system of the present invention, the front end includes a second domain for access from the client without going through the relay system, the back end includes the second domain as the backend domain, the front end accesses the second domain as the backend domain when it receives a request from the client via a URL where the second domain is a domain name without going through the relay system, and the front end may send the cookie to the client without going through the relay system when the backend generates the cookie which includes the second domain within the range of domains where the cookie can be used.
[0009] With this configuration, the device management system of the present invention, when a client accesses the frontend via a URL where the second domain is a domain name without going through a relay system and the frontend receives a request, accesses the second domain as the backend domain, the backend generates a cookie that includes the backend domain accessed by the frontend within the range of domains where cookies can be used, and when the backend generates a cookie that includes the second domain within the range of domains where cookies can be used, the frontend sends this cookie to the client without going through a relay system. Thus, a session can be established with the client not only when accessed via a relay system, but also when accessed without going through a relay system. [Effects of the Invention]
[0010] The device management system of the present invention can establish a session with a client even when accessed via a relay system from the client. [Brief explanation of the drawing]
[0011] [Figure 1] This is a block diagram of a system according to one embodiment of the present invention. [Figure 2] (a) A diagram showing an example of the front-end domain shown in Figure 1. (b) A diagram showing an example of the back-end domain shown in Figure 1. (c) A diagram showing an example of the relay system domain shown in Figure 1. [Figure 3] Figure 1 is a sequence diagram of the system's operation when a web browser accesses a device management system when an HTTP session has not been established between the web browser and the device management system. [Figure 4]Figure 1 shows a flowchart illustrating the frontend's operation when the frontend determines the backend domain to be used when sending a request to the backend. [Figure 5] This figure shows an example of a cookie generated when a web browser accesses the device management system shown in Figure 1. [Figure 6] Figure 1 is a sequence diagram of the system's operation when a web browser accesses a device management system after an HTTP session has been established between the web browser and the device management system. [Figure 7] Figure 1 is a sequence diagram illustrating the system's operation when an application accesses the device management system when an HTTP session has not been established between the application and the device management system. [Figure 8] This figure shows an example of a cookie generated when an application accesses the device management system shown in Figure 1 via a relay system. [Figure 9] Figure 1 is a sequence diagram of the system's operation when an application accesses the device management system after an HTTP session has been established between the application and the device management system. [Modes for carrying out the invention]
[0012] Hereinafter, embodiments of the present invention will be described with reference to the drawings.
[0013] First, the configuration of a system according to one embodiment of the present invention will be described.
[0014] Figure 1 is a block diagram of the system according to this embodiment.
[0015] As shown in FIG. 1, the system 10 according to this embodiment includes a device 20. The system 10 can include at least one device similar to the device 20. The devices included in the system 10 are configured by, for example, image forming apparatuses such as MFPs (Multifunction Peripherals) and dedicated printers. The devices included in the system 10 are arranged in a network such as a LAN (Local Area Network) managed by the end users of the devices.
[0016] The system 10 includes a device management system 30 that manages the devices included in the system 10 remotely. The device management system 30 can be used, for example, by a device sales company, a store, and an end user. The device management system 30 is a system for, for example, providing various information of a device to a user of the device management system 30 and executing various settings of the device on the device, such as updating the firmware of the device. The device management system 30 is realized by a computer executing a program. The device management system 30 is realized by at least one computer. The device management system 30 is realized by, for example, cloud computing such as Microsoft (registered trademark) Azure (registered trademark).
[0017] The device management system 30 includes a front end 31 and a back end 32. Requests from external clients of the device management system 30 reach the back end 32 via the front end 31 and are then processed by the back end 32.
[0018] Frontend 31 provides external integration APIs, which are Application Program Interfaces (APIs) for use from outside the device management system 30. Various types of external integration APIs can be adopted. For example, there are APIs for external clients to operate the device management system 30 and APIs for external clients to obtain information from the device management system 30. For example, external integration APIs could include a login request API, which is a request to log in to the device management system 30, and a GetDeviceInfo API, which is a request to obtain information about devices managed by the device management system 30. External integration APIs, excluding the login request API, can only be used by clients that have established a session with the device management system 30. The login request API can be used by clients that have not established a session with the device management system 30.
[0019] System 10 includes a relay system 40 that relays messages transmitted and received between a client outside the device management system 30 and the front end 31. The relay system 40 can convert a request message transmitted from a client outside the device management system 30 into a format for the external cooperation API of the front end 31 and transmit it to the external cooperation API of the front end 31, or convert a response message from the device management system 30 into a format for a client outside the device management system 30 and transmit it to a client outside the device management system 30. The relay system 40 may convert the protocol of the message as the format of the message, or convert the format of the message rather than the protocol of the message as the format of the message. The relay system 40 can be realized, for example, by an enterprise service bus such as IBM (registered trademark) Integration Bus. The relay system 40 is realized by at least one computer. The external cooperation API of the front end 31 is published via the relay system 40.
[0020] System 10 includes a web browser 51 realized by a computer such as a PC (Personal Computer) not shown as a client of the device management system 30. Similarly, System 10 can include a web browser other than the web browser 51 realized by a computer not shown as a client of the device management system 30. A user of the device management system 30 can access the device management system 30 from the web browser without going through the relay system 40.
[0021] System 10 includes an application 52 other than a web browser, implemented by a computer such as a PC (not shown), as a client for the device management system 30. Similarly, System 10 can include applications other than application 52, implemented by a computer (not shown), as clients for the device management system 30. Users of the device management system 30 can access the device management system 30 from the application via the relay system 40. As an application, for example, one that automatically performs a specific series of operations that can be performed on the device management system 30 via a web browser can be employed. Various operations can be performed on the device management system 30 by the application. For example, an operation that can be performed on the device management system 30 by the application is to create a group of users of a specific device managed by the device management system 30 and add the device users to the created group.
[0022] Figure 2(a) shows an example of a domain for the front-end 31. Figure 2(b) shows an example of a domain for the back-end 32. Figure 2(c) shows an example of a domain for the relay system 40.
[0023] The front-end 31 can be accessed from a web browser outside the device management system 30 without going through the relay system 40. On the other hand, when the front-end 31 is accessed from an application outside the device management system 30, it must be accessed via the relay system 40. As shown in Figure 2(a), the front-end 31 has a normal domain for the device management system 30 (hereinafter referred to as the "normal domain"), "○○○.com", for web browsers to access the device management system 30 without going through the relay system 40, and a domain for the device management system 30's external API (hereinafter referred to as the "API domain"), "△△△.○○○.com", for the relay system 40 to access the device management system 30. The API domain "△△△.○○○.com" is a domain for applications to access via the relay system 40, and therefore constitutes the first domain of the present invention. The normal domain "○○○.com" is a domain for web browsers to access without going through the relay system 40, and therefore constitutes the second domain of the present invention.
[0024] As shown in Figure 2(b), the backend 32 has the normal domain "○○○.com" of the device management system 30 and the domain "△△△.com" of the relay system 40, which will be described later, as its own domains.
[0025] As shown in Figure 2(c), the relay system 40 has a domain name, "△△△.com", which allows external applications of the device management system 30 to access the relay system 40. When the relay system 40 accesses the device management system 30, it is configured to access the API domain of the device management system 30, "△△△.○○○.com".
[0026] Next, we will describe the operation of system 10.
[0027] First, we will explain the operation of system 10 when accessing the device management system 30 from a web browser 51.
[0028] First, we will explain the operation of system 10 when accessing the device management system 30 from the web browser 51 in a situation where an HTTP (Hypertext Transfer Protocol) session has not been established between the web browser 51 and the device management system 30.
[0029] Figure 3 is a sequence diagram of the operation of system 10 when accessing the device management system 30 from the web browser 51 when an HTTP session has not been established between the web browser 51 and the device management system 30.
[0030] As shown in Figure 3, when the user of the device management system 30 instructs the web browser 51 to access the device management system 30, for example, the web browser 51 sends a login request to the front end 31 of the device management system 30 by accessing the URL (Uniform Resource Locator) where the domain name is the usual domain of the device management system 30, i.e., "https: / / ○○○.com" (S101). The web browser 51 includes the ID and password combination entered by the user of the device management system 30 in the login request in S101.
[0031] Figure 4 is a flowchart showing the operation of the frontend 31 when the frontend 31 determines the domain of the backend 32 to be used when sending a request to the backend 32.
[0032] When the front-end 31 is accessed from outside the device management system 30, it performs the operations shown in Figure 4.
[0033] As shown in Figure 4, the front end 31 determines the URL accessed from outside the device management system 30 (S121).
[0034] When the frontend 31 determines in S121 that the URL "https: / / ○○○.com", which is the domain name of the device management system 30's normal domain "○○○.com", has been accessed from outside the device management system 30, it decides to use the device management system 30's normal domain "○○○.com" as the domain of the backend 32 to send a request to the backend 32 (S122), and then terminates the operation shown in Figure 4.
[0035] When the frontend 31 determines in S121 that the URL "https: / / △△△.○○○.com", which is the domain name of the API domain "△△△.○○○.com" of the device management system 30, has been accessed from outside the device management system 30, it decides to use the domain "△△△.com" of the relay system 40 as the domain of the backend 32 to send a request to the backend 32 (S123), and then terminates the operation shown in Figure 4.
[0036] As shown in Figure 3, when the front-end 31 receives a login request from the web browser 51 in S101, it accesses the domain "○○○.com" of the back-end 32, which is determined by the operation shown in Figure 4, because the URL "https: / / ○○○.com" is accessed, and the normal domain of the device management system 30, "○○○.com", the front-end 31 sends a request to the back-end 32 corresponding to the login request sent from the web browser 51 in S101 (S102). The front-end 31 includes the ID and password combination included in the login request in S101 in the request sent in S102.
[0037] When the backend 32 receives a request from the frontend 31 in S102, it performs authentication in S102 in accordance with the request sent from the frontend 31 (S103). The backend 32 determines that authentication in S103 was successful if the ID and password combination included in the request sent from the frontend 31 in S102 is one that is pre-managed by the device management system 30. On the other hand, the backend 32 determines that authentication in S103 failed if the ID and password combination included in the request sent from the frontend 31 in S102 is not one that is pre-managed by the device management system 30. The explanation of what happens when authentication in S103 fails will be omitted below.
[0038] When the backend 32 determines that authentication in S103 was successful, it generates session information, which is information for the current session, on the device management system 30 (S104).
[0039] When the processing in S104 is completed, the backend 32 generates a cookie, such as the one shown in Figure 5, which includes a session ID to identify the session information generated in S104, using the domain "○○○.com" accessed by the frontend 31 in S102 (S105).
[0040] Figure 5 shows an example of a cookie generated when a web browser 51 accesses the device management system 30.
[0041] The cookie shown in Figure 5 includes the attributes SessionId, Domain, Path, and Expires, along with their values. Specifically, the cookie shown in Figure 5 has a session ID of "123456" to identify session information on the device management system 30, the domains to which this cookie can be used are the domain "○○○.com" and its subdomains accessed by the frontend 31 in S102, the path to which this cookie can be used is " / ", i.e., all paths, and the expiration date of this cookie is September 1, 2022, 00:00:00.
[0042] As shown in Figure 3, when the processing in S105 is completed, the backend 32 sends information indicating the success of authentication (hereinafter referred to as "authentication success information") and the cookie generated in S105 to the frontend 31 (S106).
[0043] When the frontend 31 receives authentication success information and a cookie from the backend 32 in S106, it sends the authentication success information and cookie received from the backend 32 to the web browser 51 in S106 (S107).
[0044] When the web browser 51 receives authentication success information and a cookie from the frontend 31 in S107, it saves the cookie sent from the frontend 31 without discarding it (S108). This is because the domain range "○○○.com" and its subdomains include the domain "○○○.com" of the frontend 31, which is the source of the cookie in S107. However, if the web browser 51 receives a cookie and the domain range included in this cookie does not include the domain of the source of this cookie, it discards the cookie and does not save it. In other words, if the domain range included in the cookie sent from the frontend 31 does not include the domain of the frontend 31, the web browser 51 discards the cookie and does not save it.
[0045] In this manner, an HTTP session is established between the web browser 51 and the device management system 30.
[0046] Next, we will describe the operation of the system 10 when the web browser 51 accesses the device management system 30 when an HTTP session has been established between the web browser 51 and the device management system 30.
[0047] Figure 6 is a sequence diagram of the operation of system 10 when a web browser 51 accesses the device management system 30 after an HTTP session has been established between the web browser 51 and the device management system 30.
[0048] As shown in Figure 6, the web browser 51 sends a specific request to the front end 31 of the device management system 30 by accessing the URL "https: / / ○○○.com", which is the domain name of the device management system 30's normal domain "○○○.com" (S141). The web browser 51 adds the cookie saved in S108 to the HTTP header of the request sent in S141.
[0049] When the frontend 31 receives a request from the web browser 51 in S141, it accesses the domain "○○○.com" of the backend 32, which is determined by the operation shown in Figure 4, because the URL "https: / / ○○○.com" is accessed by the normal domain "○○○.com" of the device management system 30. The frontend 31 then sends the request sent from the web browser 51 in S141 to the backend 32 (S142). The frontend 31 adds the cookie that was attached to the HTTP header of the request sent from the web browser 51 in S141 to the HTTP header of the request to be sent in S142.
[0050] When the backend 32 receives a request from the frontend 31 in S142, it performs processing corresponding to the request sent from the frontend 31 in S142 (S143). The backend 32 uses session information from the device management system 30, specifically the session information identified by the session ID contained in the cookie attached to the HTTP header of the request sent from the frontend 31 in S142, in the processing in S143.
[0051] The processing after step S143 will not be explained.
[0052] The above describes the operation of system 10 when accessing the device management system 30 from a web browser 51, but the operation of system 10 is the same when accessing the device management system 30 from a web browser other than web browser 51.
[0053] Next, we will describe the operation of system 10 when application 52 accesses the device management system 30.
[0054] First, we will describe the behavior of system 10 when application 52 accesses the device management system 30 in a situation where an HTTP session has not been established between application 52 and the device management system 30.
[0055] Figure 7 is a sequence diagram of the operation of system 10 when application 52 accesses the device management system 30 when an HTTP session has not been established between application 52 and the device management system 30.
[0056] As shown in Figure 7, when application 52 is instructed by a user of the device management system 30 to run application 52, for example, application 52 sends a login request to the relay system 40 by accessing the URL "https: / / △△△.com", where the domain of the relay system 40 is "△△△.com" (S161). Application 52 includes the ID and password combination that has been previously registered with application 52 in the login request in S162.
[0057] When the relay system 40 receives a login request from application 52 in S161, it accesses the URL "https: / / △△△.○○○.com", which is the domain name of the API domain of the device management system 30, and sends the login request received from application 52 in S161 to the front end 31 of the device management system 30 (S162).
[0058] When the frontend 31 receives a login request from the relay system 40 in S162, it accesses the domain "△△△.○○○.com", which is the domain name of the API domain of the device management system 30, and determines the domain "△△△.com" of the backend 32 as shown in Figure 4. The frontend 31 then sends a request to the backend 32 corresponding to the login request received from the relay system 40 in S162 (S163). The frontend 31 includes the ID and password combination included in the login request in S162 in the request sent in S163.
[0059] When the backend 32 receives a request from the frontend 31 in S163, it performs authentication in S163 in accordance with the request sent from the frontend 31 (S164). The backend 32 determines that authentication in S164 was successful if the ID and password combination included in the request sent from the frontend 31 in S163 is one that is pre-managed by the device management system 30. On the other hand, the backend 32 determines that authentication in S164 failed if the ID and password combination included in the request sent from the frontend 31 in S163 is not one that is pre-managed by the device management system 30. The explanation of what happens when authentication in S164 fails will be omitted below.
[0060] When the backend 32 determines that authentication in S164 was successful, it generates session information, which is information for the current session, on the device management system 30 (S165).
[0061] When the processing of S165 is completed, the backend 32 generates a cookie, for example as shown in Figure 8, which includes a session ID to identify the session information generated in S165, using the domain "△△△.com" accessed by the frontend 31 in S163 (S166).
[0062] Figure 8 shows an example of a cookie generated when application 52 accesses the device management system 30 via relay system 40.
[0063] The cookie shown in Figure 8 includes the attributes SessionId, Domain, Path, and Expires, along with their values. Specifically, the cookie shown in Figure 8 has a session ID of "654321" to identify session information on the device management system 30, the domains to which this cookie can be used are the domain "△△△.com" and its subdomains accessed by the frontend 31 in S163, the path to which this cookie can be used is " / ", i.e., all paths, and the expiration date of this cookie is September 1, 2022, 00:00:00.
[0064] As shown in Figure 7, once the processing in S166 is complete, the backend 32 sends the authentication success information and the cookie generated in S166 to the frontend 31 (S167).
[0065] When the front-end 31 receives authentication success information and a cookie from the back-end 32 in S167, it transmits the authentication success information and cookie received from the back-end 32 to the relay system 40 in S167 (S168).
[0066] When the relay system 40 receives authentication success information and a cookie from the front end 31 in S168, it sends the authentication success information and cookie received from the front end 31 to the application 52 in S168 (S169).
[0067] When application 52 receives authentication success information and a cookie from the relay system 40 in S169, it saves the cookie sent from the relay system 40 without discarding it (S170) because the domain range "△△△.com" and its subdomains, which are included in the cookie sent from the relay system 40 in S169, include the domain "△△△.com" of the relay system 40, which is the source of the cookie in S169. However, when a cookie is sent, if the domain range included in this cookie does not include the domain of the source of this cookie, application 52 discards the cookie and does not save it. In other words, if the domain range included in the cookie sent from the relay system 40 does not include the domain of the relay system 40, application 52 discards the cookie and does not save it.
[0068] As described above, an HTTP session is established between application 52 and device management system 30. Within the session established between application 52 and device management system 30, application 52 can use external APIs other than the API for login requests.
[0069] Next, we will describe the operation of system 10 when application 52 accesses the device management system 30 after an HTTP session has been established between application 52 and the device management system 30.
[0070] Figure 9 is a sequence diagram of the operation of system 10 when application 52 accesses the device management system 30 after an HTTP session has been established between application 52 and the device management system 30.
[0071] As shown in Figure 9, application 52 sends a specific request to relay system 40 by accessing the URL "https: / / △△△.com", where the domain of relay system 40 is "△△△.com" (S181). Application 52 adds the cookie saved in S170 to the HTTP header of the request sent in S181.
[0072] When the relay system 40 receives a request from application 52 in S181, it accesses the URL "https: / / △△△.○○○.com", which is the domain name of the API domain of the device management system 30, and sends the request received from application 52 in S181 to the frontend 31 of the device management system 30 (S182). The relay system 40 adds the cookie that was attached to the HTTP header of the request received from application 52 in S181 to the HTTP header of the request to be sent in S182.
[0073] When the frontend 31 receives a request from the relay system 40 in S182, it accesses the domain "△△△.○○○.com", which is the domain name of the API domain of the device management system 30, and determines the domain of the backend 32, "△△△.com", as shown in Figure 4. The frontend 31 then sends the request received from the relay system 40 in S182 to the backend 32 (S183). The frontend 31 then adds the cookie that was attached to the HTTP header of the request received from the relay system 40 in S182 to the HTTP header of the request to be sent in S183.
[0074] When the backend 32 receives a request from the frontend 31 in S183, it performs processing corresponding to the request sent from the frontend 31 in S183 (S184). The backend 32 uses session information from the device management system 30, which is identified by the session ID contained in the cookie attached to the HTTP header of the request sent from the frontend 31 in S183, in the processing in S184.
[0075] The processing after the S184 operation will not be explained.
[0076] The above describes the operation of system 10 when application 52 accesses the device management system 30, but the operation of system 10 is the same when applications other than application 52 access the device management system 30.
[0077] Please note that "○○○.com", "△△△.○○○.com", and "△△△.com" in this embodiment are merely examples.
[0078] As explained above, when the device management system 30 receives a login request from the application 52 to the frontend 31 via the relay system 40 to the URL "https: / / △△△.○○○.com" where the API domain "△△△.○○○.com" is the domain name (S161~S162), the frontend 31 accesses the relay system 40's domain "△△△.com" as the backend 32's domain (S163), and the backend 32 generates a cookie that includes the backend 32's domain "△△△.com" accessed by the frontend 31 within the range of domains where cookies can be used (S166), and uses the cookie. When a cookie containing the relay system 40's domain "△△△.com" is generated by the backend 32 in S166 within the range of available domains, the frontend 31 sends this cookie to application 52 via the relay system 40 (S168-S169). This prevents application 52 from discarding the cookie due to the relay system 40's domain "△△△.com" not being included in the range of domains contained in the cookie sent to application 52 via the relay system 40. As a result, a session can be established between application 52 and application 52 even when accessed via the relay system 40.
[0079] When the device management system 30 receives a login request from the frontend 31 via the relay system 40 when the frontend 31 is accessed by a web browser 51 to the URL "https: / / ○○○.com" where the domain name is normally "○○○.com", without going through the relay system 40 (S101), the frontend 31 accesses the normal domain "○○○.com" as the domain of the backend 32 (S102), the backend 32 generates a cookie that includes the domain "○○○.com" accessed by the frontend 31 within the range of domains where cookies can be used (S105), and when the backend 32 generates a cookie in S105 that includes the normal domain "○○○.com" within the range of domains where cookies can be used, the frontend 31 sends this cookie to the web browser 51 without going through the relay system 40 (S107). Therefore, a session can be established with the client not only when accessed via the relay system 40 from an application 52 acting as a client (see Figure 7), but also when accessed without going through the relay system 40 from a web browser 51 acting as a client (see Figure 3). [Explanation of Symbols]
[0080] 20 devices 30 Device Management Systems 31 Front End 32 backend 40 Relay System 51. Web browser (client) 52. Application (Client)
Claims
1. A device management system for managing devices, A backend that generates cookies for a session between an external client of the device management system and the device management system, A frontend that provides an API for use by the aforementioned client via the relay system. Equipped with, The front end comprises a first domain for access from the client via the relay system, The backend includes the domain of the relay system as the backend's domain, When the front-end receives an API request from the client via the relay system to a URL where the first domain is a domain name, it accesses the relay system's domain as the back-end domain. The backend generates a cookie that includes the domain of the backend accessed by the frontend within the range of domains where the cookie can be used. The device management system is characterized in that the front end transmits the cookie to the client via the relay system when the cookie is generated by the backend and the domain of the relay system is within the range of domains in which the cookie can be used.
2. The front end includes a second domain for access from the client without going through the relay system, The backend includes the second domain as the backend's domain, When the front-end receives a request from the client via a URL where the second domain is a domain name, without going through the relay system, it accesses the second domain as the back-end domain. The device management system according to claim 1, characterized in that the front end transmits the cookie to the client without going through the relay system when the cookie is generated by the backend and the cookie includes the second domain within the range of domains where the cookie can be used.
Citation Information
Patent Citations
JP1971038131B1
Network system
JP2011223278A
Request distribution system, management system, and control method thereof
JP2016218530A
Non-intrusive security enforcement for federated single sign-on (SSO)
JP2020502616A
Method and apparatus for transmitting application programming interface API requests
JP2021511702A