DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Priority
Applicant’s claim for the benefit of a prior-filed application under 35 U.S.C. 119(e) or under 35 U.S.C. 120, 121, 365(c), or 386(c) is acknowledged.
Receipt is acknowledged of certified copies of papers required by 37 CFR 1.55.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 17 April 2025 and 29 May 2025 have been considered by the examiner.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claim 2 is rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 2 recites the limitation "the concerned entity" in line 7. There is insufficient antecedent basis for this limitation in the claim as no concerned entity is previously recited.
The following is a quotation of 35 U.S.C. 112(d):
(d) REFERENCE IN DEPENDENT FORMS.—Subject to subsection (e), a claim in dependent form shall contain a reference to a claim previously set forth and then specify a further limitation of the subject matter claimed. A claim in dependent form shall be construed to incorporate by reference all the limitations of the claim to which it refers.
The following is a quotation of pre-AIA 35 U.S.C. 112, fourth paragraph:
Subject to the following paragraph [i.e., the fifth paragraph of pre-AIA 35 U.S.C. 112], a claim in dependent form shall contain a reference to a claim previously set forth and then specify a further limitation of the subject matter claimed. A claim in dependent form shall be construed to incorporate by reference all the limitations of the claim to which it refers.
Claims 14 and 15 are rejected under 35 U.S.C. 112(d) or pre-AIA 35 U.S.C. 112, 4th paragraph, as being of improper dependent form for failing to further limit the subject matter of the claim upon which it depends, or for failing to include all the limitations of the claim upon which it depends. Claims 14 and 15 recite non transitory computer readable media comprising program code with instructions that execute claims 1 and 7. Claims 14 and 15 do not further limit claims 1 or 7 as they do not actually require the particulars of claims 1 or 7. Applicant may cancel the claim(s), amend the claim(s) to place the claim(s) in proper dependent form, rewrite the claim(s) in independent form, or present a sufficient showing that the dependent claim(s) complies with the statutory requirements.
Claim Rejections - 35 USC § 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1-6, 11 and 14 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by U.S. Patent Application Publication No. 2013/0227634 by Pal et al.
As to claims 1, 11 and 14, Pal discloses a processing method/entity/medium comprising:
processing a request to execute a service in a communication network, from a service consuming entity to an executing entity of said service, wherein the processing is implemented at an intermediate entity configured to receive messages from the service consuming entity intended for the service executing entity or from the service executing entity intended for the service consuming entity (Pal: Page 4, Sec 43-46; “[0043] FIG. 1 shows a block diagram of a service-level entity protection architecture according to one embodiment of the present invention. In a distributed computer system architecture (e.g., system 100), a protection scheme may be provided that receives service requests (e.g., service request 102) originating from one or more entities (e.g., a client 101), and determines whether the service requests should be forwarded to a service-level entity (e.g., element 106). [0044] In one embodiment, a service request processor (e.g., processor 104) may be provided that analyzes received service requests and determines whether the requests are "safe" and can be received by the service-level entity. It is appreciated that it may be beneficial to provide an interface that is accessed by other entities, and wherein the underlying service is not accessed directly. Elements of the protection architecture receive service requests, analyze them, and determine whether they can be safely executed by the underlying service-level entity. [0045] According to one embodiment, the architecture includes a splitter entity 103 that receives a service request (e.g., service request 103) and sends a copy of the request to the service request processor (e.g., processor 104). The service request processor performs one or more analyses on the request, and determines whether the service request should be processed by the service-level entity. [0046] In parallel to sending the request to the service request processor, the splitter sends a copy of the request to a memory where it is stored pending an outcome of the analysis by the service request processor. If it is determined that the service request should be processed by the service-level entity, the service request is sent to the service-level entity to be processed. In one embodiment, service requests may be escrowed in a memory (e.g., memory 105) and released to service-level entities as appropriate. The memory may include any number of devices or software constructs capable of storing one or more service requests. Requests (e.g., requests 107) may be arranged in a queue or list structure and may be released to the service-level entity in an order that the requests were received.”), and comprises:
-receiving said request to execute the service from the service consuming entity (Pal: Page 4, Sec 43-46; “[0043] FIG. 1 shows a block diagram of a service-level entity protection architecture according to one embodiment of the present invention. In a distributed computer system architecture (e.g., system 100), a protection scheme may be provided that receives service requests (e.g., service request 102) originating from one or more entities (e.g., a client 101), and determines whether the service requests should be forwarded to a service-level entity (e.g., element 106). [0044] In one embodiment, a service request processor (e.g., processor 104) may be provided that analyzes received service requests and determines whether the requests are "safe" and can be received by the service-level entity. It is appreciated that it may be beneficial to provide an interface that is accessed by other entities, and wherein the underlying service is not accessed directly. Elements of the protection architecture receive service requests, analyze them, and determine whether they can be safely executed by the underlying service-level entity. [0045] According to one embodiment, the architecture includes a splitter entity 103 that receives a service request (e.g., service request 103) and sends a copy of the request to the service request processor (e.g., processor 104). The service request processor performs one or more analyses on the request, and determines whether the service request should be processed by the service-level entity. [0046] In parallel to sending the request to the service request processor, the splitter sends a copy of the request to a memory where it is stored pending an outcome of the analysis by the service request processor. If it is determined that the service request should be processed by the service-level entity, the service request is sent to the service-level entity to be processed. In one embodiment, service requests may be escrowed in a memory (e.g., memory 105) and released to service-level entities as appropriate. The memory may include any number of devices or software constructs capable of storing one or more service requests. Requests (e.g., requests 107) may be arranged in a queue or list structure and may be released to the service-level entity in an order that the requests were received.”); and
-deciding whether or not to transmit for validation the request to execute the service to a validating entity of said request, distinct from the service executing entity, before transmitting said request to the service executing entity (Pal: Page 4, Sec 43-46; “[0043] FIG. 1 shows a block diagram of a service-level entity protection architecture according to one embodiment of the present invention. In a distributed computer system architecture (e.g., system 100), a protection scheme may be provided that receives service requests (e.g., service request 102) originating from one or more entities (e.g., a client 101), and determines whether the service requests should be forwarded to a service-level entity (e.g., element 106). [0044] In one embodiment, a service request processor (e.g., processor 104) may be provided that analyzes received service requests and determines whether the requests are "safe" and can be received by the service-level entity. It is appreciated that it may be beneficial to provide an interface that is accessed by other entities, and wherein the underlying service is not accessed directly. Elements of the protection architecture receive service requests, analyze them, and determine whether they can be safely executed by the underlying service-level entity. [0045] According to one embodiment, the architecture includes a splitter entity 103 that receives a service request (e.g., service request 103) and sends a copy of the request to the service request processor (e.g., processor 104). The service request processor performs one or more analyses on the request, and determines whether the service request should be processed by the service-level entity. [0046] In parallel to sending the request to the service request processor, the splitter sends a copy of the request to a memory where it is stored pending an outcome of the analysis by the service request processor. If it is determined that the service request should be processed by the service-level entity, the service request is sent to the service-level entity to be processed. In one embodiment, service requests may be escrowed in a memory (e.g., memory 105) and released to service-level entities as appropriate. The memory may include any number of devices or software constructs capable of storing one or more service requests. Requests (e.g., requests 107) may be arranged in a queue or list structure and may be released to the service-level entity in an order that the requests were received.”).
As to claim 2, Pal further discloses, wherein the processing comprises:
-transmitting said request to execute the service to the service validating entity (Pal: Page 4, Sec 43-46; “[0043] FIG. 1 shows a block diagram of a service-level entity protection architecture according to one embodiment of the present invention. In a distributed computer system architecture (e.g., system 100), a protection scheme may be provided that receives service requests (e.g., service request 102) originating from one or more entities (e.g., a client 101), and determines whether the service requests should be forwarded to a service-level entity (e.g., element 106). [0044] In one embodiment, a service request processor (e.g., processor 104) may be provided that analyzes received service requests and determines whether the requests are "safe" and can be received by the service-level entity. It is appreciated that it may be beneficial to provide an interface that is accessed by other entities, and wherein the underlying service is not accessed directly. Elements of the protection architecture receive service requests, analyze them, and determine whether they can be safely executed by the underlying service-level entity. [0045] According to one embodiment, the architecture includes a splitter entity 103 that receives a service request (e.g., service request 103) and sends a copy of the request to the service request processor (e.g., processor 104). The service request processor performs one or more analyses on the request, and determines whether the service request should be processed by the service-level entity. [0046] In parallel to sending the request to the service request processor, the splitter sends a copy of the request to a memory where it is stored pending an outcome of the analysis by the service request processor. If it is determined that the service request should be processed by the service-level entity, the service request is sent to the service-level entity to be processed. In one embodiment, service requests may be escrowed in a memory (e.g., memory 105) and released to service-level entities as appropriate. The memory may include any number of devices or software constructs capable of storing one or more service requests. Requests (e.g., requests 107) may be arranged in a queue or list structure and may be released to the service-level entity in an order that the requests were received.”);
-receiving at least one response message from among a validation information message and an execution report message (Pal: Page 4, Sec 43-46; “[0043] FIG. 1 shows a block diagram of a service-level entity protection architecture according to one embodiment of the present invention. In a distributed computer system architecture (e.g., system 100), a protection scheme may be provided that receives service requests (e.g., service request 102) originating from one or more entities (e.g., a client 101), and determines whether the service requests should be forwarded to a service-level entity (e.g., element 106). [0044] In one embodiment, a service request processor (e.g., processor 104) may be provided that analyzes received service requests and determines whether the requests are "safe" and can be received by the service-level entity. It is appreciated that it may be beneficial to provide an interface that is accessed by other entities, and wherein the underlying service is not accessed directly. Elements of the protection architecture receive service requests, analyze them, and determine whether they can be safely executed by the underlying service-level entity. [0045] According to one embodiment, the architecture includes a splitter entity 103 that receives a service request (e.g., service request 103) and sends a copy of the request to the service request processor (e.g., processor 104). The service request processor performs one or more analyses on the request, and determines whether the service request should be processed by the service-level entity. [0046] In parallel to sending the request to the service request processor, the splitter sends a copy of the request to a memory where it is stored pending an outcome of the analysis by the service request processor. If it is determined that the service request should be processed by the service-level entity, the service request is sent to the service-level entity to be processed. In one embodiment, service requests may be escrowed in a memory (e.g., memory 105) and released to service-level entities as appropriate. The memory may include any number of devices or software constructs capable of storing one or more service requests. Requests (e.g., requests 107) may be arranged in a queue or list structure and may be released to the service-level entity in an order that the requests were received.”); and
-transmitting the received response message to the concerned entity from among the service consuming entity and the service executing entity, based on the received response message (Pal: Page 4, Sec 43-46; “[0043] FIG. 1 shows a block diagram of a service-level entity protection architecture according to one embodiment of the present invention. In a distributed computer system architecture (e.g., system 100), a protection scheme may be provided that receives service requests (e.g., service request 102) originating from one or more entities (e.g., a client 101), and determines whether the service requests should be forwarded to a service-level entity (e.g., element 106). [0044] In one embodiment, a service request processor (e.g., processor 104) may be provided that analyzes received service requests and determines whether the requests are "safe" and can be received by the service-level entity. It is appreciated that it may be beneficial to provide an interface that is accessed by other entities, and wherein the underlying service is not accessed directly. Elements of the protection architecture receive service requests, analyze them, and determine whether they can be safely executed by the underlying service-level entity. [0045] According to one embodiment, the architecture includes a splitter entity 103 that receives a service request (e.g., service request 103) and sends a copy of the request to the service request processor (e.g., processor 104). The service request processor performs one or more analyses on the request, and determines whether the service request should be processed by the service-level entity. [0046] In parallel to sending the request to the service request processor, the splitter sends a copy of the request to a memory where it is stored pending an outcome of the analysis by the service request processor. If it is determined that the service request should be processed by the service-level entity, the service request is sent to the service-level entity to be processed. In one embodiment, service requests may be escrowed in a memory (e.g., memory 105) and released to service-level entities as appropriate. The memory may include any number of devices or software constructs capable of storing one or more service requests. Requests (e.g., requests 107) may be arranged in a queue or list structure and may be released to the service-level entity in an order that the requests were received.”).
As to claim 3, Pal further discloses wherein the at least one received response message comprises a validation information message from the validating entity comprising a validation result, the validation information message is transmitted to the service consuming entity when the validation result is negative, and the request to execute the service is transmitted to the service executing entity when the validation result is positive (Pal: Page 4, Sec 43-46; “[0043] FIG. 1 shows a block diagram of a service-level entity protection architecture according to one embodiment of the present invention. In a distributed computer system architecture (e.g., system 100), a protection scheme may be provided that receives service requests (e.g., service request 102) originating from one or more entities (e.g., a client 101), and determines whether the service requests should be forwarded to a service-level entity (e.g., element 106). [0044] In one embodiment, a service request processor (e.g., processor 104) may be provided that analyzes received service requests and determines whether the requests are "safe" and can be received by the service-level entity. It is appreciated that it may be beneficial to provide an interface that is accessed by other entities, and wherein the underlying service is not accessed directly. Elements of the protection architecture receive service requests, analyze them, and determine whether they can be safely executed by the underlying service-level entity. [0045] According to one embodiment, the architecture includes a splitter entity 103 that receives a service request (e.g., service request 103) and sends a copy of the request to the service request processor (e.g., processor 104). The service request processor performs one or more analyses on the request, and determines whether the service request should be processed by the service-level entity. [0046] In parallel to sending the request to the service request processor, the splitter sends a copy of the request to a memory where it is stored pending an outcome of the analysis by the service request processor. If it is determined that the service request should be processed by the service-level entity, the service request is sent to the service-level entity to be processed. In one embodiment, service requests may be escrowed in a memory (e.g., memory 105) and released to service-level entities as appropriate. The memory may include any number of devices or software constructs capable of storing one or more service requests. Requests (e.g., requests 107) may be arranged in a queue or list structure and may be released to the service-level entity in an order that the requests were received.”).
As to claim 4, Pal further discloses wherein the processing comprises, in response to a positive validation result, the obtaining by the intermediate entity of an identifier of the service executing entity, and in that the request to execute the service is transmitted to the service executing entity using said obtained identifier (Pal: Page 4, Sec 43-46; “[0043] FIG. 1 shows a block diagram of a service-level entity protection architecture according to one embodiment of the present invention. In a distributed computer system architecture (e.g., system 100), a protection scheme may be provided that receives service requests (e.g., service request 102) originating from one or more entities (e.g., a client 101), and determines whether the service requests should be forwarded to a service-level entity (e.g., element 106). [0044] In one embodiment, a service request processor (e.g., processor 104) may be provided that analyzes received service requests and determines whether the requests are "safe" and can be received by the service-level entity. It is appreciated that it may be beneficial to provide an interface that is accessed by other entities, and wherein the underlying service is not accessed directly. Elements of the protection architecture receive service requests, analyze them, and determine whether they can be safely executed by the underlying service-level entity. [0045] According to one embodiment, the architecture includes a splitter entity 103 that receives a service request (e.g., service request 103) and sends a copy of the request to the service request processor (e.g., processor 104). The service request processor performs one or more analyses on the request, and determines whether the service request should be processed by the service-level entity. [0046] In parallel to sending the request to the service request processor, the splitter sends a copy of the request to a memory where it is stored pending an outcome of the analysis by the service request processor. If it is determined that the service request should be processed by the service-level entity, the service request is sent to the service-level entity to be processed. In one embodiment, service requests may be escrowed in a memory (e.g., memory 105) and released to service-level entities as appropriate. The memory may include any number of devices or software constructs capable of storing one or more service requests. Requests (e.g., requests 107) may be arranged in a queue or list structure and may be released to the service-level entity in an order that the requests were received.”).
As to claim 5, Pal further discloses wherein said at least one received response message comprises a service execution report message sent by the service executing entity and in that the said service execution report message is transmitted to the service consuming entity (Pal: Page 4, Sec 43-46; “[0043] FIG. 1 shows a block diagram of a service-level entity protection architecture according to one embodiment of the present invention. In a distributed computer system architecture (e.g., system 100), a protection scheme may be provided that receives service requests (e.g., service request 102) originating from one or more entities (e.g., a client 101), and determines whether the service requests should be forwarded to a service-level entity (e.g., element 106). [0044] In one embodiment, a service request processor (e.g., processor 104) may be provided that analyzes received service requests and determines whether the requests are "safe" and can be received by the service-level entity. It is appreciated that it may be beneficial to provide an interface that is accessed by other entities, and wherein the underlying service is not accessed directly. Elements of the protection architecture receive service requests, analyze them, and determine whether they can be safely executed by the underlying service-level entity. [0045] According to one embodiment, the architecture includes a splitter entity 103 that receives a service request (e.g., service request 103) and sends a copy of the request to the service request processor (e.g., processor 104). The service request processor performs one or more analyses on the request, and determines whether the service request should be processed by the service-level entity. [0046] In parallel to sending the request to the service request processor, the splitter sends a copy of the request to a memory where it is stored pending an outcome of the analysis by the service request processor. If it is determined that the service request should be processed by the service-level entity, the service request is sent to the service-level entity to be processed. In one embodiment, service requests may be escrowed in a memory (e.g., memory 105) and released to service-level entities as appropriate. The memory may include any number of devices or software constructs capable of storing one or more service requests. Requests (e.g., requests 107) may be arranged in a queue or list structure and may be released to the service-level entity in an order that the requests were received.”).
As to claim 6, Pal further discloses wherein the decision whether or not to transmit said request to the service validating entity is made based on at least one given decision criterion relating to at least one network operation indicator and/or at least one type of request to execute the service (Pal: Page 4, Sec 43-46; “[0043] FIG. 1 shows a block diagram of a service-level entity protection architecture according to one embodiment of the present invention. In a distributed computer system architecture (e.g., system 100), a protection scheme may be provided that receives service requests (e.g., service request 102) originating from one or more entities (e.g., a client 101), and determines whether the service requests should be forwarded to a service-level entity (e.g., element 106). [0044] In one embodiment, a service request processor (e.g., processor 104) may be provided that analyzes received service requests and determines whether the requests are "safe" and can be received by the service-level entity. It is appreciated that it may be beneficial to provide an interface that is accessed by other entities, and wherein the underlying service is not accessed directly. Elements of the protection architecture receive service requests, analyze them, and determine whether they can be safely executed by the underlying service-level entity. [0045] According to one embodiment, the architecture includes a splitter entity 103 that receives a service request (e.g., service request 103) and sends a copy of the request to the service request processor (e.g., processor 104). The service request processor performs one or more analyses on the request, and determines whether the service request should be processed by the service-level entity. [0046] In parallel to sending the request to the service request processor, the splitter sends a copy of the request to a memory where it is stored pending an outcome of the analysis by the service request processor. If it is determined that the service request should be processed by the service-level entity, the service request is sent to the service-level entity to be processed. In one embodiment, service requests may be escrowed in a memory (e.g., memory 105) and released to service-level entities as appropriate. The memory may include any number of devices or software constructs capable of storing one or more service requests. Requests (e.g., requests 107) may be arranged in a queue or list structure and may be released to the service-level entity in an order that the requests were received.”).
Claims 7-10, 12 and 15 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by U.S. Patent Application Publication No. 2023/0056432 by Wu et al.
As to claims 7, 12 and 15, Wu discloses a validation method/entity/medium comprising:
validating a request to execute a service in a communication network, said request having been sent by an entity referred to as a service consuming entity of said network to a service executing entity, the validating being implemented at a service validating entity distinct from said executing entity (Wu: Fig 4A; Page 4, Sec 75 – Page 5, Sec 80; “0075] FIG. 4A is a flow chart of a service communication method according to some embodiments. The method will be described in conjunction with the operations shown in FIG. 4A. [0076] Operation 101: Receive an authentication request sent by a service access process. [0077] Here, the electronic device receives an authentication request sent by the service access process, for example, an authentication interface (such as a certain port) may be predetermined in the electronic device, and when the electronic device receives an invocation request of the service access process for the authentication interface, the invocation request is taken as the authentication request. The service access process may be an application process of a certain application client and may also be used for proxying the application client, which will be described later. The embodiments do not limit the type of service, which may be, for example, an instant communication service or a video service, etc. [0078] Operation 102: Perform synchronous authentication processing on the service access process, and perform asynchronous verification processing on the service access process. [0079] Here, for the service access process, synchronous authentication processing and asynchronous verification processing are performed to verify the validity thereof An embodiment does not define an execution order of the synchronous verification processing and the asynchronous verification processing. For example, they may be executed simultaneously. For another example, when the synchronous verification processing result is verification success, the asynchronous verification processing is executed then.
[0080] An embodiment also does not define the processing modes of the synchronous verification processing and the asynchronous verification processing. For example, verification objects of the synchronous verification processing and the asynchronous verification processing may be the same, and the verification objects are process information about a service access process, and the difference between the two lies in that the synchronous verification processing is executed only once, while the asynchronous verification processing is executed periodically multiple times.”)
and comprising:
-receiving said request to execute the service from an intermediate entity configured to receive messages to or from the service executing entity (Wu: Fig 4A; Page 4, Sec 75 – Page 5, Sec 80; “0075] FIG. 4A is a flow chart of a service communication method according to some embodiments. The method will be described in conjunction with the operations shown in FIG. 4A. [0076] Operation 101: Receive an authentication request sent by a service access process. [0077] Here, the electronic device receives an authentication request sent by the service access process, for example, an authentication interface (such as a certain port) may be predetermined in the electronic device, and when the electronic device receives an invocation request of the service access process for the authentication interface, the invocation request is taken as the authentication request. The service access process may be an application process of a certain application client and may also be used for proxying the application client, which will be described later. The embodiments do not limit the type of service, which may be, for example, an instant communication service or a video service, etc. [0078] Operation 102: Perform synchronous authentication processing on the service access process, and perform asynchronous verification processing on the service access process. [0079] Here, for the service access process, synchronous authentication processing and asynchronous verification processing are performed to verify the validity thereof An embodiment does not define an execution order of the synchronous verification processing and the asynchronous verification processing. For example, they may be executed simultaneously. For another example, when the synchronous verification processing result is verification success, the asynchronous verification processing is executed then. [0080] An embodiment also does not define the processing modes of the synchronous verification processing and the asynchronous verification processing. For example, verification objects of the synchronous verification processing and the asynchronous verification processing may be the same, and the verification objects are process information about a service access process, and the difference between the two lies in that the synchronous verification processing is executed only once, while the asynchronous verification processing is executed periodically multiple times.”);
-checking a validity of said request to execute the service, comprising obtaining a validation result (Wu: Fig 4A; Page 5, Sec 81-85; “[0081] Operation 103: Determine service key information allocated for the service access process according to a synchronous verification processing result of the service access process. [0082] For example, it can be judged whether to determine the service key information allocated for the service access process according to the synchronous verification processing result of the service access process. The service key information includes at least a key, and may further include a key identifier, etc. The service key information may be pre-allocated for a service access process or may be allocated in real time, which is not limited. [0083] In order to further improve the security, the electronic device may also periodically update the service key information allocated for the service access process, and perform invalidation processing (also referred to as invalid processing) on the service key information before the update to trigger the service access process to resend the authentication request to acquire the updated service key information. [0084] In some embodiments, the authentication request includes an authentication request address. The above-mentioned determination of the service key information allocated for the service access process can be realized in such a manner: allocating different service key information with respect to authentication request addresses sent by the different service access processes, and allocating different service key information with respect to different authentication request addresses sent by the same service access process; allocating different service key information with respect to authentication request addresses sent by the different service access processes, and allocating same service key information with respect to different authentication request addresses sent by the same service access process; and allocating same service key information with respect to authentication request addresses sent by the different service access processes, and allocating same service key information with respect to different authentication request addresses sent by the same service access process. [0085] Here, the electronic device may predetermine a plurality of authentication request addresses in advance, so that the service access process transmits the authentication request according to the authentication request addresses. The electronic device can implement various allocation schemes according to two factors of the service access process itself and the authentication request address upon determining the service key information allocated for the service access process.”; and
-executing at least one action based on the validation result obtained (Wu: Fig 4A; Page 6, Sec 91-96; “[0091] Here, service key information allocated for the service access process is determined when a synchronous verification processing result of the service access process is verification success; and when a synchronous verification processing result of the service access process is verification failure, the service access process is proved to be invalid, the service access process is refused to be allocated with service key information, and the communication connection with the service access process can also be disconnected. That is, the synchronous verification processing on the service access process may be essentially regarded as a preliminary verification of whether the service access process is valid. [0092] In some embodiments, when the synchronous verification processing result of the service access process is verification failure, error information may be sent to the service access process to inform the service access process to resend the authentication request or to disconnect the communication connection with the service access process. In addition, if the synchronous verification processing result of the service access process is verification failure when the service access process is undergoing asynchronous verification processing, the asynchronous verification processing on the service access process may be interrupted to save computational resources. [0093] Operation 104: Send the service key information to the service access process for encrypted service communication with the service access process based on the service key information.
[0094] The electronic device sends the service key information allocated for the service access process to the service access process, such that encrypted service communication with the service access process can be performed based on the service key information. For example, the service key information includes a symmetric key, then the service access process may encrypt the data according to the symmetric key, and send the encrypted data to the electronic device, so that the electronic device decrypts the received encrypted data according to the symmetric key; and likewise, the electronic device may encrypt the data according to the symmetric key and send the encrypted data to the service access process so that the service access process decrypts the encrypted data according to the symmetric key. [0095] Operation 105: Control a communication connection used for bearing the encrypted service communication with the service access process according to an asynchronous verification processing result of the service access process. [0096] When the asynchronous verification processing result of the service access process is obtained herein, a communication connection for carrying encrypted service communication with the service access process according to the asynchronous verification processing result. An embodiment does not limit the type of communication connection. The communication connection may be, for example, a socket connection.”).
As to claim 8, Wu further discloses wherein said at least one action comprises transmitting a validation information message comprising the validation result to the intermediate entity (Wu: Fig 4A; Page 6, Sec 91-96; “[0091] Here, service key information allocated for the service access process is determined when a synchronous verification processing result of the service access process is verification success; and when a synchronous verification processing result of the service access process is verification failure, the service access process is proved to be invalid, the service access process is refused to be allocated with service key information, and the communication connection with the service access process can also be disconnected. That is, the synchronous verification processing on the service access process may be essentially regarded as a preliminary verification of whether the service access process is valid. [0092] In some embodiments, when the synchronous verification processing result of the service access process is verification failure, error information may be sent to the service access process to inform the service access process to resend the authentication request or to disconnect the communication connection with the service access process. In addition, if the synchronous verification processing result of the service access process is verification failure when the service access process is undergoing asynchronous verification processing, the asynchronous verification processing on the service access process may be interrupted to save computational resources. [0093] Operation 104: Send the service key information to the service access process for encrypted service communication with the service access process based on the service key information. [0094] The electronic device sends the service key information allocated for the service access process to the service access process, such that encrypted service communication with the service access process can be performed based on the service key information. For example, the service key information includes a symmetric key, then the service access process may encrypt the data according to the symmetric key, and send the encrypted data to the electronic device, so that the electronic device decrypts the received encrypted data according to the symmetric key; and likewise, the electronic device may encrypt the data according to the symmetric key and send the encrypted data to the service access process so that the service access process decrypts the encrypted data according to the symmetric key. [0095] Operation 105: Control a communication connection used for bearing the encrypted service communication with the service access process according to an asynchronous verification processing result of the service access process. [0096] When the asynchronous verification processing result of the service access process is obtained herein, a communication connection for carrying encrypted service communication with the service access process according to the asynchronous verification processing result. An embodiment does not limit the type of communication connection. The communication connection may be, for example, a socket connection.”).
As to claim 9, Wu further discloses wherein, when the validation result is positive, said at least one action comprises transmitting said request to execute the service to the service executing entity (Wu: Fig 4A; Page 6, Sec 91-96; “[0091] Here, service key information allocated for the service access process is determined when a synchronous verification processing result of the service access process is verification success; and when a synchronous verification processing result of the service access process is verification failure, the service access process is proved to be invalid, the service access process is refused to be allocated with service key information, and the communication connection with the service access process can also be disconnected. That is, the synchronous verification processing on the service access process may be essentially regarded as a preliminary verification of whether the service access process is valid. [0092] In some embodiments, when the synchronous verification processing result of the service access process is verification failure, error information may be sent to the service access process to inform the service access process to resend the authentication request or to disconnect the communication connection with the service access process. In addition, if the synchronous verification processing result of the service access process is verification failure when the service access process is undergoing asynchronous verification processing, the asynchronous verification processing on the service access process may be interrupted to save computational resources. [0093] Operation 104: Send the service key information to the service access process for encrypted service communication with the service access process based on the service key information. [0094] The electronic device sends the service key information allocated for the service access process to the service access process, such that encrypted service communication with the service access process can be performed based on the service key information. For example, the service key information includes a symmetric key, then the service access process may encrypt the data according to the symmetric key, and send the encrypted data to the electronic device, so that the electronic device decrypts the received encrypted data according to the symmetric key; and likewise, the electronic device may encrypt the data according to the symmetric key and send the encrypted data to the service access process so that the service access process decrypts the encrypted data according to the symmetric key. [0095] Operation 105: Control a communication connection used for bearing the encrypted service communication with the service access process according to an asynchronous verification processing result of the service access process. [0096] When the asynchronous verification processing result of the service access process is obtained herein, a communication connection for carrying encrypted service communication with the service access process according to the asynchronous verification processing result. An embodiment does not limit the type of communication connection. The communication connection may be, for example, a socket connection.”).
As to claim 10, Wu further discloses wherein said at least one action further comprises receiving a response message from the service executing entity comprising a service execution report and transmitting said response message to the intermediate entity (Wu: Fig 4A; Page 6, Sec 91-96; “[0091] Here, service key information allocated for the service access process is determined when a synchronous verification processing result of the service access process is verification success; and when a synchronous verification processing result of the service access process is verification failure, the service access process is proved to be invalid, the service access process is refused to be allocated with service key information, and the communication connection with the service access process can also be disconnected. That is, the synchronous verification processing on the service access process may be essentially regarded as a preliminary verification of whether the service access process is valid. [0092] In some embodiments, when the synchronous verification processing result of the service access process is verification failure, error information may be sent to the service access process to inform the service access process to resend the authentication request or to disconnect the communication connection with the service access process. In addition, if the synchronous verification processing result of the service access process is verification failure when the service access process is undergoing asynchronous verification processing, the asynchronous verification processing on the service access process may be interrupted to save computational resources. [0093] Operation 104: Send the service key information to the service access process for encrypted service communication with the service access process based on the service key information. [0094] The electronic device sends the service key information allocated for the service access process to the service access process, such that encrypted service communication with the service access process can be performed based on the service key information. For example, the service key information includes a symmetric key, then the service access process may encrypt the data according to the symmetric key, and send the encrypted data to the electronic device, so that the electronic device decrypts the received encrypted data according to the symmetric key; and likewise, the electronic device may encrypt the data according to the symmetric key and send the encrypted data to the service access process so that the service access process decrypts the encrypted data according to the symmetric key. [0095] Operation 105: Control a communication connection used for bearing the encrypted service communication with the service access process according to an asynchronous verification processing result of the service access process. [0096] When the asynchronous verification processing result of the service access process is obtained herein, a communication connection for carrying encrypted service communication with the service access process according to the asynchronous verification processing result. An embodiment does not limit the type of communication connection. The communication connection may be, for example, a socket connection.”).
Priority
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
U.S. Patent No. 8,640,189 to Ernst et al. discloses verification services
U.S. Patent Application Publication No. 2019/0058713 by Pala discloses using an intermediary to grant network access
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MICHAEL S MCNALLY whose telephone number is (571)270-1599. The examiner can normally be reached Monday-Friday, 8:30 AM - 5:00 PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Jeffrey L Nickerson can be reached at (469)295-9235. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
MICHAEL S. MCNALLY
Primary Examiner
Art Unit 2432
/Michael S McNally/Primary Examiner, Art Unit 2432
Prosecution Insights