DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Applicant initially filed claims 1-20 on June 27, 2024.
Applicant filed a preliminary amendment on July 12, 2024 where claims 1-46 were cancelled and claims 47-66 were added.
It should be noted that Applicant has not filed claims 21-46 (these claim numbers are associated with claims in the parent applications but not a part of the current application). Although these claims do not exist, Examiner will treat claims 21-46 as being officially cancelled.
Examiner respectfully requests that if Applicant files a continuation/divisional of this or any related Application; that any added claims in that application should use the next available number (e.g., #21 assuming the original 20 claims are filed) as opposed to what Applicant has been doing. For the present application, Applicant should continue numbering from claim 66 (e.g., adding claims 67-??).
Claims 47-66 are pending and have been examined.
Examiner Request
The Applicant is requested to indicate where in the specification there is support for amendments to claims should Applicant amend. The purpose of this is to reduce potential 35 USC 112(a) or 35 USC 112 first paragraph issues that can arise when claims are amended without support in the specification. The Examiner thanks the Applicant in advance.
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 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.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 47-51, 53-61, and 63-66 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Ljujic, US Patent Application Publication NO 2015/0371219.
Regarding claims 47 and 57;
(Claim 57) A method for a mobile interface, the method comprising:
recognizing, by an application on a smart phone, an appearance of a contactless transaction card within a real-time digital image captured by a digital camera of the smart phone,
See Ljujic [0169] As with a standard image personalised card, a video card also allows for a preview functionality prior to confirming the purchase of the card (step S52), which is shown in FIG. 13. The user opens the preview screen and a camera associated with the user device 10 is turned on. The user then puts any card 11 in front of the camera, and the AR software recognises the shape of the card and then tracks the position of the recognised card. The proposed design and video is then overlaid 12 on the card in the user device display 13. Such a system does not require the card to be printed, but simply recognises the shape of any card in order to demonstrate the AR functionality and expected look/results. This AR functionality could also be utilised for previewing an image card.
communicating, by the application on the smart phone, with an authentication server to confirm that the contactless transaction card is one of a plurality of contactless transaction cards associated with a provider of an account holder account,
See Ljujic [0173] The user or recipient places the card in the view of an image capture device such as a camera of the user device used for reading the card (step S60). A recognition system is then used to recognise the card and perform a matching process. Once a match is made (between the card and the video), the user device either intakes a video stream or downloads the video, is in view of the camera. The card image is examined using a processor of the user device in order to attempt to identify unique features in the image being examined, such as the image itself or other recognition elements such as the PAN or an MRD (step S61). The processor uses a particular processing methodology forming part of the mobile app, which is stored on the user device. If the card image is used as an identifying unique feature, and since the image consists of pixels and pixels are interpreted as a series of numbers, the image recognition system detects these patterns. Once a suitable pattern has been recognised this recognised pattern is transmitted from the user device over a network to the service provider server. The service provider server then compares the received image pattern information and compares this with images stored in its database (step S62). Once the server finds a match, the server then obtains the video associated with the image and transmits this image to the user device (step S63).
constructing, by the application in response to such confirmation, an augmented reality image containing indicia related to the account holder account, and
See Ljujic [0173] The service provider server then compares the received image pattern information and compares this with images stored in its database (step S62). Once the server finds a match, the server then obtains the video associated with the image and transmits this image to the user device (step S63). The user device then displays the video overlaid on the card in the output image of the user device screen (step S64).
[0178] It will be appreciated that the augmented reality system need not provide an overlaid video, but could instead provide an overlaid image.
displaying, through a display on the smart phone, the augmented reality image superimposed over the real-time digital image of the contactless transaction card from a camera on the smart phone.
See Ljujic [0173] The service provider server then compares the received image pattern information and compares this with images stored in its database (step S62). Once the server finds a match, the server then obtains the video associated with the image and transmits this image to the user device (step S63). The user device then displays the video overlaid on the card in the output image of the user device screen (step S64).
[0178] It will be appreciated that the augmented reality system need not provide an overlaid video, but could instead provide an overlaid image.
Regarding claims 48 and 58;
(Claim 58) The method of claim 57, wherein the action to recognize an appearance of the contactless transaction card includes processing the real-time digital image to determine if a background pattern of the contactless transaction card matches one of a plurality of non-unique card background patterns associated with the provider of the account holder account.
See Ljujic [0173] The user or recipient places the card in the view of an image capture device such as a camera of the user device used for reading the card (step S60). A recognition system is then used to recognise the card and perform a matching process. Once a match is made (between the card and the video), the user device either intakes a video stream or downloads the video, is in view of the camera. The card image is examined using a processor of the user device in order to attempt to identify unique features in the image being examined, such as the image itself or other recognition elements such as the PAN or an MRD (step S61).
Regarding claims 49 and 59;
(Claim 59) The method of claim 57 wherein the action to communicate with the authentication server is carried out only in response to a determination that the background pattern matches one of the plurality of non-unique card background patterns.
See Ljujic [0173] The processor uses a particular processing methodology forming part of the mobile app, which is stored on the user device. If the card image is used as an identifying unique feature, and since the image consists of pixels and pixels are interpreted as a series of numbers, the image recognition system detects these patterns. Once a suitable pattern has been recognised this recognised pattern is transmitted from the user device over a network to the service provider server. The service provider server then compares the received image pattern information and compares this with images stored in its database (step S62). Once the server finds a match, the server then obtains the video associated with the image and transmits this image to the user device (step S63).
Regarding claims 50 and 60;
(Claim 60) The method of claim 57, further comprising, establishing communication with the contactless transaction card over a near field communication interface.
See Ljujic [0009] The information identifying the user may be obtained using near field communication NFC.
Regarding claims 51 and 61;
(Claim 61) The method of claim 60, further comprising, receiving account information from a processor chip on the contactless transaction card.
See Ljujic [0176] In the case of NFC, the initial matching of NFC chip is carried out during the personalisation of the card at the CPB. During the personalisation process, the CPBs equipment reads the serial number associated with the NFC chip and transfers it back to the service provider under the same unique identifier that was used for the user image. The service provider then associates chip number to the image and video. It will be appreciated that the CPB could encode the uID to the NFC tag so that the CPB need not send the chip serial number back to the service provider's system.
[0106] Due to the importance of financial data security, card issuers cannot and/or will not usually share account holder information with 3rd parties. For this reason instead of identifying the user and user image in accordance with their financial information, an alternative identification mechanism is provided for linking the user of the card personalisation service provider's service to an account held with their bank and in particular to a card perso file for that user, which is data required for a financial transaction card such as the magnetic stripe, chip, and emboss/indent data. This alternative identification mechanism is discussed below.
Regarding claims 53 and 63;
(Claim 63) The method of claim 61, further comprising, transmitting a display authorization request to the authentication server.
See Ljujic [0018] The method may further comprise receiving, at the server associated with the service provider, a request to access a financial card personalisation website hosted by the service provider, and providing access to the website responsive to receipt of the request, wherein the website includes the computer operable instructions. The service provider may be operated by the card issuer and therefore the request may be received at and processed by the card issuer. Alternatively, the request may also be received at a card issuer website and forwarded onto a service provider arranged to provide the card personalisation process for the card issuer.
Regarding claims 54 and 64;
(Claim 64) The method of claim 63, wherein the display authorization request includes the account information.
See Ljujic [0185] In an embodiment of the invention OCR is utilised in order to speed up the credit card saving procedure. OCR is used to recognize the credit card number the user wants to use for online payment. A camera of a user device takes a picture of a credit or debit card in the field of vision of the camera. The OCR function reads the data embossed on the card. For example, the OCR function reads the Personal Account Number (PAN) which is the long 16-digit number printed on any credit or debit card, valid from/to dates, issue number (if applicable), and/or cardholder name.
[0173] The user or recipient places the card in the view of an image capture device such as a camera of the user device used for reading the card (step S60). A recognition system is then used to recognise the card and perform a matching process. Once a match is made (between the card and the video), the user device either intakes a video stream or downloads the video, is in view of the camera. The card image is examined using a processor of the user device in order to attempt to identify unique features in the image being examined, such as the image itself or other recognition elements such as the PAN or an MRD (step S61).
Regarding claims 55 and 65;
(Claim 65) The method of claim 57, wherein constructing the augmented reality image further comprises determining a pose of the contactless transaction card relative to the digital camera.
See Ljujic [0173] The image is tracked in space using AR SDK and the position of the AR overlay is adjusted according to personalized card position. For non-standard shaped cards, the mobile device is able to detect the borders of the object (i.e. the card), so that it can determine the exact shape on which the AR content would be displayed. Consequently, the video can be displayed within the borders of the physical card.
Regarding claim 66;
(Claim 66) A mobile interface device, comprising:
a data processor; a communication interface in communication with the data processor and configured for selective communication with an authentication server via a network;
a near field communication interface in communication with the data processor and configured for communication with a contactless transaction card; a user interface comprising at least a user input device and a display device; a digital camera configured to capture a real-time digital image of the contactless transaction for real-time display on the display device;
a memory block accessible by the data processor and containing a transaction card application with instructions to be carried out by the data processor, the transaction card application being configured to:
See Ljujic [0086] In the system of FIG. 1, a user is able to create an image that they want printed on the card at a user device 100. The user device includes at least a processor arranged to perform the processing for creation of the image, a memory used to store the image being processed, and a communications unit for communicating with other devices and across one or more networks. The user device 100 is depicted as a laptop computer in FIG. 1, but it will be appreciated that the user device could be any computing device capable of performing such processing such as a desktop computer, mobile smart phone, tablet, PDA, or such like. The user is therefore able to edit, manipulate and process the image on the user device.
[0009] The scanning may be performed by a camera of the user device obtaining an image and a processor of the user device processing the image to identify information identifying the user… The information identifying the user may be obtained using near field communication NFC.
See also Figure 1
receive an authentication request for an account associated with the contactless transaction card based on a near field communication from the contactless transaction card;
See Ljujic [0018] The method may further comprise receiving, at the server associated with the service provider, a request to access a financial card personalisation website hosted by the service provider, and providing access to the website responsive to receipt of the request, wherein the website includes the computer operable instructions. The service provider may be operated by the card issuer and therefore the request may be received at and processed by the card issuer. Alternatively, the request may also be received at a card issuer website and forwarded onto a service provider arranged to provide the card personalisation process for the card issuer.
[0097] When registering, the user can create a user account profile. The user profile is stored on the service provider server. The user information may include one or more of the user's first name, surname, address, DOB, and a log-in password. Depending on the system, various other security provisions could be provided for authentication purposes.
[0169] As with a standard image personalised card, a video card also allows for a preview functionality prior to confirming the purchase of the card (step S52), which is shown in FIG. 13. The user opens the preview screen and a camera associated with the user device 10 is turned on. The user then puts any card 11 in front of the camera, and the AR software recognises the shape of the card and then tracks the position of the recognised card. The proposed design and video is then overlaid 12 on the card in the user device display 13. Such a system does not require the card to be printed, but simply recognises the shape of any card in order to demonstrate the AR functionality and expected look/results. This AR functionality could also be utilised for previewing an image card.
transmit the authentication request to the authentication server;
See Ljujic [0097] When registering, the user can create a user account profile. The user profile is stored on the service provider server. The user information may include one or more of the user's first name, surname, address, DOB, and a log-in password. Depending on the system, various other security provisions could be provided for authentication purposes.
[0169] As with a standard image personalised card, a video card also allows for a preview functionality prior to confirming the purchase of the card (step S52), which is shown in FIG. 13. The user opens the preview screen and a camera associated with the user device 10 is turned on. The user then puts any card 11 in front of the camera, and the AR software recognises the shape of the card and then tracks the position of the recognised card. The proposed design and video is then overlaid 12 on the card in the user device display 13. Such a system does not require the card to be printed, but simply recognises the shape of any card in order to demonstrate the AR functionality and expected look/results. This AR functionality could also be utilised for previewing an image card.
receive authentication from the authentication server for the account;
See Ljujic [0099] Once the user has successfully passed authentication, the user is presented with a card designer module where the user is able to design their card at step S5. The design of the personalisation card will be described in detail later in this document.
in response to authentication, construct an augmented reality image containing indicia related to the account holder account, and
See Ljujic [0173] The service provider server then compares the received image pattern information and compares this with images stored in its database (step S62). Once the server finds a match, the server then obtains the video associated with the image and transmits this image to the user device (step S63). The user device then displays the video overlaid on the card in the output image of the user device screen (step S64).
[0178] It will be appreciated that the augmented reality system need not provide an overlaid video, but could instead provide an overlaid image.
display the augmented reality image superimposed over the real-time digital image of the contactless transaction card.
See Ljujic [0173] The service provider server then compares the received image pattern information and compares this with images stored in its database (step S62). Once the server finds a match, the server then obtains the video associated with the image and transmits this image to the user device (step S63). The user device then displays the video overlaid on the card in the output image of the user device screen (step S64).
[0178] It will be appreciated that the augmented reality system need not provide an overlaid video, but could instead provide an overlaid image.
Claim Rejections - 35 USC § 103
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.
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 of this title, 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.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 52 and 62 are rejected under 35 U.S.C. 103 as being unpatentable over Ljujic as applied to claims 47-51, 53-61, and 63-66 above, and further in view of Auten, US Patent Application Publication NO 2016/0019449.
Regarding claims 52 and 62;
The Primary reference does not explicitly teach:
(Claim 62) The method of claim 61, wherein the account information from the processor chip on the contactless transaction card is encrypted.
The reference Auten teaches:
wherein the account information from the processor chip on the contactless transaction card is encrypted.
See Auten [0048] [0048] In one embodiment microcomputer unit (MCU) 25 is implemented using part no. STM32L151C6U6 available from STMicroelectronics or equivalent low power MCU. The MCU handles all the interfaces, stores any required data, performs encryption/decryption, etc. It processes the instructions sent by the external smartphone (or cell phone) application and modifies the card operation. The processor may also have its own application that assists the card to communicate to a phone, other cards, payment devices, and networks. It also may use the information from the buttons and communicate to the LEDs to provide user input and output, have a lockout timer, help with security and more. The specifics of the programming of the MCU are not important for an understanding of the invention and, except for the emulator functionality are well within the abilities of those skilled in the art based on the descriptions provided herein.
[0063] All the information transmitted between the card and the application on the phone are encrypted with high standards to avoid “man in the middle” attacks or data leak/manipulation, or other attacks.
It would have been obvious to one of ordinary skill in the art before the effective filing date to include in the account information of the primary reference, the ability to encrypt that information as taught by Auten since the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable. Additional motivation includes encrypting the sensitive information makes the processing of the information more secure.
Double Patenting
In their present form, claims 47-66 are not subject to a double patenting rejection. Claims 47-65 were subject to a restriction in application 18/222342 as well as a similar restriction in 17/533801. Claim 66 is similar to allowed claims from the parent applications, but for the allowable subject matter in those claims (therefore it cannot be said they are obvious variants of each other). While these claims are not subject to a double patenting rejection at the moment, there exists the possibility that Applicant could amend the current claims into a position where a double patenting rejection is required.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MICHAEL J WARDEN whose telephone number is (571)272-9602. The examiner can normally be reached M-F; 9-6 CDT.
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, Bennett M Sigmond can be reached at 303-297-4411. 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 J. WARDEN/
Examiner
Art Unit 3694
/BENNETT M SIGMOND/Supervisory Patent Examiner, Art Unit 3694
Prosecution Insights