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 .
This action is responsive to the application filed June 20, 2023 and preliminary amendment filed June 20, 2023, in which claims 9-11 have been amended, claims 21-23 have been canceled.
Thus, claims 1-20 are pending and are presenting for examination.
Examiner Notes
Examiner cites particular columns and line numbers in the references as applied to the claims below for the convenience of the applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested that, in preparing responses, the applicant fully consider the references in entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the examiner.
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 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.
Claim Objections
Claims 7-8 and 19-20 are objected to because of the following informalities:
As to claim 7, lines 4-6, recited to include the following limitation “the number n”, “the total number q” and “the number p” appeared to be insufficient antecedent basis for this limitation in the claim. Appropriate correction is required.
As to claim 8, lines (4, 7, 10, and 11), recited to include the following limitation “the number of usable slave processing units”, “the ith data acquisition task”, and “the Hash operation” appeared to be insufficient antecedent basis for this limitation in the claim. Furthermore, there is no clearly define of what variable n in expression (i.e., 1≤i≤n) is. Appropriate correction is required.
As to claim 19, lines 2-4, recited to include the following limitation “the number n”, “the total number q” and “the number p” appeared to be insufficient antecedent basis for this limitation in the claim. Appropriate correction is required.
As to claim 20, lines (3, 6, and 8-10), recited to include the following limitation “the number of usable slave processing units”, “the ith data acquisition task”, and “the Hash operation” appeared to be insufficient antecedent basis for this limitation in the claim. Furthermore, there is no clearly define of what variable n in expression (i.e., 1≤i≤n) is. Appropriate correction is required.
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims 12-20 in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) is/are:
“the background service module is configured with”, and “the interception calling unit is configured to acquire” in claim 12,
“an acquisition unit configured to acquire”, “a mapping unit configured to perform”, and “an adding unit configured to add” in claim 13,
“the mapping unit is configured to acquire” in claim 14,
“ the data synchronization unit is configured to acquire” in claim 15,
“the mapping unit is configured to acquire” in claim 16,
“the modification unit is configured to synchronously modify” in claim 17,
“an acquisition sub-unit configured to acquire”, “generation sub-unit configured to generate”, “an allocation sub-unit configured to allocate”, “a summarizing sub-unit configured to receive”, and “each slave processing unit is configured to acquire” in claim 18,
“the generation sub- unit is configured to: calculate” in claim 19, and
“the allocation sub-unit is configured to: determine” in claim 20.
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
A review of the specification shows that the following appears to be the corresponding structure described in the specification for the 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph limitation: ““the background service module is configured with, the interception calling unit is configured to acquire, an acquisition unit configured to acquire, a mapping unit configured to perform, an adding unit configured to add, the mapping unit is configured to acquire, the data synchronization unit is configured to acquire, the modification unit is configured to synchronously modify, an acquisition sub-unit configured to acquire, generation sub-unit configured to generate, an allocation sub-unit configured to allocate, a summarizing sub-unit configured to receive, each slave processing unit is configured to acquire, the generation sub- unit is configured to: calculate, and the allocation sub-unit is configured to: determine” are corresponding to components of Figs. 4-10 and paragraphs 0127, 0155, and associated text of application specification:
Based on the same inventive concept, the embodiment of the present disclosure further provides a service system, which is the above service processing end. FIG. 11 is a block diagram of a structure of a service system according to an embodiment of the present disclosure; FIG. 12 is a block diagram of a structure of a customized serializer of FIG. 11. FIG. 13 is a block diagram of a structure of a maintenance module according to an embodiment of the present disclosure. As shown in FIG. 11 to FIG. 13, the service system 1 includes: a background service module 11 and a serialization module 12, where the background service module 1 is configured with a service data acquisition interface, and the serialization module 12 includes an interception calling unit 121 and a customized serializer 122 which is registered in the serialization module 12 in advance. It will be understood by one of ordinary skill in the art that all or some of the steps of the methods, systems, functional blocks in the systems may be implemented as software, firmware, hardware, or suitable combinations thereof. In a hardware implementation, the division between functional modules referred to in the above description does not necessarily correspond to a division of physical components; for example, one physical component may have multiple functions, or one function or step may be performed by several physical components in cooperation. Some or all of the physical components may be implemented as software executed by a processor, such as a central processing unit, digital signal processor, or microprocessor, or as hardware, or as an integrated circuit, such as an application specific integrated circuit.
Therefore, the structure describes in the specification is/are hardware or part of hardware. If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claim 11 is rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter. The claim does not fall within at least one of the four categories of patent eligible subject matter because the specification does not explicitly exclude signals or electromagnetic waves, which are non-statutory subject matters, from the claimed “computer-readable storage medium”.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1 and 9-13 are rejected under 35 U.S.C. 103 as being unpatentable over ANZHIRUOSU, “Use of the jsonserialize annotation” of IDS Filed 12/06/2023, in view of Rueger et al. (US 20140181783 A1, hereinafter Rueger).
As to claim 1, ANZHIRUOSU discloses a service code interpretation weaving method, comprising:
acquiring data generated by a background service module– (e.g., the back end is expected to display a corresponding Chinese character at a front end, for example: the constant value = ID_CARD, and the front end expects a return = ID_CARD, involving the use of the JsonSerialize annotation —see at least pages 1-2); and
calling a customized serializer to perform an interpretation mapping on a code field value of a preset service code field in the entity class object, to obtain a code interpretation value corresponding to the code field value, and adding the code interpretation value to the entity class object -- (e.g., using get method to retrieve the mapping values of the user-define implementation class as such : Implementation: the following annotation is added to getXXX() method corresponding to dto: @JsonSerialize(using =CodeToNameJsonSerialize.class), wherein CodeToNameJsonSerialize is a user-defined implementation class, and the implementation class is required to inherit this abstract class JsonSerializer —see at least pages 1-2).
It is to note that while ANZHIRUOSU discloses acquiring the data generated by the background service module – (e.g., the back end is expected to display a corresponding Chinese character at a front end, for example: the constant value = ID_CARD, and the front end expects a return = ID_CARD, involving the use of the JsonSerialize annotation —see at least pages 1-2), but does not explicitly disclose; however, Rueger, in an analogous art, discloses an entity class object generated by the background service module -- (e.g., server 340 creating model class 360 –entity class object – from the client 310 requesting as such transformer 350 …create instances of the generated model classes 360 in the ABAP programming language. Server 340 uses a copy of the same XSD file to deserialize the XML file that was used by client 310 to serialize instances of generated model entities into the XML file—see at least 0019, 0023-0026, Fig. 1-Fig. 3, and associated text).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated Rueger’s teaching into back end of ANZHIRUOSU’s teaching for further efficiently and accurately in defining, creating, and deploying of user-defined implementation class within heterogeneous environment as seen in Rueger (e.g., 0001 and 0019).
As to claim 9, modified ANZHIRUOSU with Rueger discloses wherein after adding the code interpretation value to the entity class object, the method further comprises: performing a serialization processing on the entity class object comprising the code interpretation value, to obtain serialized data - (e.g., using get method to retrieve the mapping values of the user-define implementation class as such : Implementation: the following annotation is added to getXXX() method corresponding to dto: @JsonSerialize(using =CodeToNameJsonSerialize.class), wherein CodeToNameJsonSerialize is a user-defined implementation class, and the implementation class is required to inherit this abstract class JsonSerializer —see ANZHIRUOSU, at least pages 1-2); and
feeding back the serialized data to the service request end (e.g., the back end is expected to display a corresponding Chinese character at a front end, for example: the constant value = ID_CARD, and the front end expects a return = ID_CARD, involving the use of the JsonSerialize annotation —see ANZHIRUOSU, at least pages 1-2).
As to claim 10, modified ANZHIRUOSU with Rueger discloses wherein the preset service code field in the entity class object is configured with a customized serialization annotation specifying the customized serializer; the customized serialization annotation is @JsonSerialize annotation; and the customized serializer is a customized jackson serializer --(e.g., using get method to retrieve the mapping values of the user-define implementation class as such : Implementation: the following annotation is added to getXXX() method corresponding to dto: @JsonSerialize(using =CodeToNameJsonSerialize.class), wherein CodeToNameJsonSerialize is a user-defined implementation class, and the implementation class is required to inherit this abstract class JsonSerializer —see ANZHIRUOSU, at least pages 1-2).
As to claim 11, it is to note that ANZHIRUOSU does not explicitly disclose; however, Rueger, in an analogous art, discloses a computer-readable storage medium – (e.g., memory 525 and system 500 of Fig. 5 – see at least 0034, Fig. 5, and associated text) having stored thereon computer-executable instructions which, when executed by a processor, implement the method claim 1.
Thus, it would have been obvious to one of ordinary skill in the art before the effective
filing date of the claimed invention to have incorporated Rueger’s teaching into ANZHIRUOSU’s teaching and still accomplish predictable result due to memory is used to stored computer-executable instructions as a well-known in the field of art.
As to claim 12, ANZHIRUOSU discloses a service system, comprising:
a background service module and a serialization module, wherein the background service module is configured with a service data acquisition interface – (e.g., a back end performs a query for a dictionary constant value – see at least page 1), and the serialization module comprises an interception calling unit and a customized serializer; the service data acquisition interface is configured to generate a corresponding data in response to a service data calling request – (e.g., the back end is expected to display a corresponding Chinese character at a front end, for example: the constant value = ID_CARD, and the front end expects a return = ID_CARD, involving the use of the JsonSerialize annotation—see at least pages 1-2);
the interception calling unit is configured to acquire the data generated by the background service module – (e.g., the back end is expected to display a corresponding Chinese character at a front end, for example: the constant value = ID_CARD, and the front end expects a return = ID_CARD, involving the use of the JsonSerialize annotation —see at least pages 1-2); and
the customized serializer is configured to perform an interpretation mapping on a code field value of a preset service code field in the entity class object, to obtain a code interpretation value corresponding to the code field value, and add the code interpretation value to the entity class object – (e.g., using get method to retrieve the mapping values of the user-define implementation class as such : Implementation: the following annotation is added to getXXX() method corresponding to dto: @JsonSerialize(using = CodeToNameJsonSerialize.class), wherein CodeToNameJsonSerialize is a user-defined implementation class, and the implementation class is required to inherit this abstract class JsonSerializer —see at least pages 1-2).
It is to note that while ANZHIRUOSU discloses the interception calling unit is configured to acquire the data generated by the background service module – (e.g., the back end is expected to display a corresponding Chinese character at a front end, for example: the constant value = ID_CARD, and the front end expects a return = ID_CARD, involving the use of the JsonSerialize annotation —see at least pages 1-2), but does not explicitly disclose; however, Rueger, in an analogous art, discloses the service data acquisition unit to generate a corresponding entity class object generated by the background service module -- (e.g., server 340 creating model class 360 –entity class object – from the client 310 as such transformer 350 …create (valid) instances of the generated model classes 360 in the ABAP programming language. Server 340 uses a copy of the same XSD file to deserialize the XML file that was used by client 310 to serialize instances of generated model entities into the XML file—see at least 0019, 0023-0026, Fig. 1-Fig. 3, and associated text).
Thus, it would have been obvious to one of ordinary skill in the art before the effective
filing date of the claimed invention to have incorporated Rueger’s teaching into back end of ANZHIRUOSU’s teaching for further efficiently and accurately in defining, creating, deploying and deploying of user-defined implementation class within heterogeneous environment as seen in Rueger (e.g., 0001 and 0019).
As to claim 13, modified ANZHIRUOSU with Rueger discloses wherein the customized serializer comprises: an acquisition unit configured to acquire the code field value of the preset service code field --(e.g., the back end is expected to display a corresponding Chinese character at a front end, for example: the constant value = ID_CARD, and the front end expects a return = ID_CARD, involving the use of the JsonSerialize annotation —see ANZHIRUOSU, at least pages 1-2); a mapping unit configured to perform the interpretation mapping on the code field value to obtain the code interpretation value corresponding to the code field value; and an adding unit configured to add the code interpretation value to the entity class object --(e.g., using get method to retrieve the mapping values of the user-define implementation class as such : Implementation: the following annotation is added to getXXX() method corresponding to dto: @JsonSerialize(using = CodeToNameJsonSerialize.class), wherein CodeToNameJsonSerialize is a user-defined implementation class, and the implementation class is required to inherit this abstract class JsonSerializer —see ANZHIRUOSU, at least pages 1-2).
Claims 2-4 and 14-16 are rejected under 35 U.S.C. 103 as being unpatentable over ANZHIRUOSU, in view of Rueger, and in further view of Stoyanova et al. (US 8024425 B2, hereinafter Stoyanova).
As to claim 2, it is to note that while ANZHIRUOSU discloses wherein the performing the interpretation mapping on the code field value of the preset service code field comprises: acquiring the code interpretation value corresponding to the code field value, wherein the mapping data comprise different code field values and code interpretation values corresponding to the code field values -- (e.g., using get method to retrieve the mapping values of the user-define implementation class as such : Implementation: the following annotation is added to getXXX() method corresponding to dto: @JsonSerialize(using =CodeToNameJsonSerialize.class), wherein CodeToNameJsonSerialize is a user-defined implementation class, and the implementation class is required to inherit this abstract class JsonSerializer —see at least pages 1-2) but does not explicitly disclose that the value corresponding to the code field value according to pre-stored mapping data; however, Stoyanova, in an analogous art, discloses acquiring the code interpretation value
corresponding to the code field value according to pre-stored mapping data – (e.g., storing the mapping values: such as key-to end points within system memory for easy access as such the message key-to-endpoint method information mapping into the Web services data 613, the mapping information for the Web service may be accessed more quickly by being cached along with the Web service data 613 – see at least col. 14: 63 to col. 15: 5, col. 45: 20-27, Fig. 3, and associated text).
Thus, it would have been obvious to one of ordinary skill in the art before the effective
filing date of the claimed invention to have incorporated Stoyanova into modified teaching of ANZHIRUOSU with Rueger for further improving performing due to quicky access of the pre-store data within user-defined implementation class as seen in Stoyanova (e.g. least col. 14: 63 to col. 15: 5).
As to claim 3, it is to note that while ANZHIRUOSU discloses wherein before the performing the interpretation mapping on the code field value of the preset service code field, the method further comprises: acquiring the mapping data-- (e.g., using get method to retrieve the mapping values of the user-define implementation class as such : Implementation: the following annotation is added to getXXX() method corresponding to dto: @JsonSerialize(using =CodeToNameJsonSerialize.class), wherein CodeToNameJsonSerialize is a user-defined implementation class, and the implementation class is required to inherit this abstract class JsonSerializer —see at least pages 1-2) but does not explicitly disclose; however, Stoyanova, in an analogous art, discloses that data are from a storage server, and storing the mapping data in a cache– (e.g., storing the mapping values: such as key-to end points within system memory for easy access as such the message key-to-endpoint method information mapping into the Web services data 613, the mapping information for the Web service may be accessed more quickly by being cached along with the Web service data 613 – see at least col. 14: 63 to col. 15: 5, col. 45: 20-27, Fig. 3, and associated text).
Thus, it would have been obvious to one of ordinary skill in the art before the effective
filing date of the claimed invention to have incorporated Stoyanova into modified teaching of ANZHIRUOSU with Rueger for further improving performing due to quicky access of the pre-store data within user-defined implementation class as seen in Stoyanova (e.g. least col. 14: 63 to col. 15: 5).
As to claim 4, it is to note that while ANZHIRUOSU discloses wherein the acquiring the code interpretation value corresponding to the code field value according to the pre- stored mapping data comprises : acquiring the code interpretation value corresponding to the code field value-- (e.g., using get method to retrieve the mapping values of the user-define implementation class as such : Implementation: the following annotation is added to getXXX() method corresponding to dto: @JsonSerialize(using =CodeToNameJsonSerialize.class), wherein CodeToNameJsonSerialize is a user-defined implementation class, and the implementation class is required to inherit this abstract class JsonSerializer —see at least pages 1-2) but does not explicitly disclose; however, Stoyanova, in an analogous art, discloses that the acquiring data are according to the mapping data stored in the cache – (e.g., storing the mapping values: such as key-to end points within system memory for easy access as such the message key-to-endpoint method information mapping into the Web services data 613, the mapping information for the Web service may be accessed more quickly by being cached along with the Web service data 613 – see at least col. 14: 63 to col. 15: 5, col. 45: 20-27, Fig. 3, and associated text).
Thus, it would have been obvious to one of ordinary skill in the art before the effective
filing date of the claimed invention to have incorporated Stoyanova into modified teaching of ANZHIRUOSU with Rueger for further improving performing due to quicky access of the pre-store data within user-defined implementation class as seen in Stoyanova (e.g. least col. 14: 63 to col. 15: 5).
As to claim 14, it is to note that while ANZHIRUOSU discloses wherein the mapping unit is configured to acquire the code interpretation value corresponding to the code field value, wherein the mapping data comprise different code field values and code interpretation values corresponding to the code field values -- (e.g., using get method to retrieve the mapping values of the user-define implementation class as such : Implementation: the following annotation is added to getXXX() method corresponding to dto: @JsonSerialize(using =CodeToNameJsonSerialize.class), wherein CodeToNameJsonSerialize is a user-defined implementation class, and the implementation class is required to inherit this abstract class JsonSerializer —see at least pages 1-2) but does not explicitly disclose that the value corresponding to the code field value according to pre-stored mapping data; however, Stoyanova, in an analogous art, discloses acquiring the code interpretation value
corresponding to the code field value according to pre-stored mapping data – (e.g., storing the mapping values: such as key-to end points within system memory for easy access as such the message key-to-endpoint method information mapping into the Web services data 613, the mapping information for the Web service may be accessed more quickly by being cached along with the Web service data 613 – see at least col. 14: 63 to col. 15: 5, col. 45: 20-27, Fig. 3, and associated text).
Thus, it would have been obvious to one of ordinary skill in the art before the effective
filing date of the claimed invention to have incorporated Stoyanova into modified teaching of ANZHIRUOSU with Rueger for further improving performing due to quicky access of the pre-store data within user-defined implementation class as seen in Stoyanova (e.g. least col. 14: 63 to col. 15: 5).
As to claim 15, it is to note that while ANZHIRUOSU discloses further comprising: a maintenance module, wherein the maintenance module comprises: a data synchronization unit; and the data synchronization unit is configured to acquire the mapping data-- (e.g., using get method to retrieve the mapping values of the user-define implementation class as such : Implementation: the following annotation is added to getXXX() method corresponding to dto: @JsonSerialize(using =CodeToNameJsonSerialize.class), wherein CodeToNameJsonSerialize is a user-defined implementation class, and the implementation class is required to inherit this abstract class JsonSerializer —see at least pages 1-2) but does not explicitly disclose; however, Stoyanova, in an analogous art, discloses that data are from a storage server, and storing the mapping data in a cache– (e.g., storing the mapping values: such as key-to end points within system memory for easy access as such the message key-to-endpoint method information mapping into the Web services data 613, the mapping information for the Web service may be accessed more quickly by being cached along with the Web service data 613 – see at least col. 14: 63 to col. 15: 5, col. 45: 20-27, Fig. 3, and associated text).
Thus, it would have been obvious to one of ordinary skill in the art before the effective
filing date of the claimed invention to have incorporated Stoyanova into modified teaching of ANZHIRUOSU with Rueger for further improving performing due to quicky access of the pre-store data within user-defined implementation class as seen in Stoyanova (e.g. least col. 14: 63 to col. 15: 5).
As to claim 16, it is to note that while ANZHIRUOSU discloses wherein the mapping unit is configured to acquire the code interpretation value corresponding to the code field value- (e.g., using get method to retrieve the mapping values of the user-define implementation class as such : Implementation: the following annotation is added to getXXX() method corresponding to dto: @JsonSerialize(using =CodeToNameJsonSerialize.class), wherein CodeToNameJsonSerialize is a user-defined implementation class, and the implementation class is required to inherit this abstract class JsonSerializer —see at least pages 1-2) but does not explicitly disclose; however, Stoyanova, in an analogous art, discloses that the acquiring data are according to the mapping data stored in the cache – (e.g., storing the mapping values: such as key-to end points within system memory for easy access as such the message key-to-endpoint method information mapping into the Web services data 613, the mapping information for the Web service may be accessed more quickly by being cached along with the Web service data 613 – see at least col. 14: 63 to col. 15: 5, col. 45: 20-27, Fig. 3, and associated text).
Thus, it would have been obvious to one of ordinary skill in the art before the effective
filing date of the claimed invention to have incorporated Stoyanova into modified teaching of ANZHIRUOSU with Rueger for further improving performing due to quicky access of the pre-store data within user-defined implementation class as seen in Stoyanova (e.g. least col. 14: 63 to col. 15: 5).
Allowable Subject Matter
Claims 5-8 and 17-20 are objected to as being dependent upon rejected base claims, but would be allowable if further rewritten or amended to overcome the objection(s), set forth in this Office action and to include all the limitations of the base claim and any intervening claims.
Conclusion
The prior art made of record and not relied upon (cited on 892 form) is considered pertinent to application disclosure.
Mueller et al. (US-20040230556-A1) disclose upon receiving a request from an application, using generic API to instantiate the persistence service class to include interfaces and classes that execute file data storage.
Chan et al. (US-20140289717-A1) discloses detecting serialization schemes used in software applications
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MARINA LEE whose telephone number is (571)270-1648. The examiner can normally be reached Monday to Friday (8 am to 4: 30 pm ET).
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, Hyung S. Sough can be reached on (571)-272-6799. 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.
/MARINA LEE/Primary Examiner, Art Unit 2192